Subject: Food for thought: Shifting layer 2 functionality to layer 3 with IPv6

From: Walter Zimmer <[email-masked]>
Date: Mon, 16 Dec 2002 12:11:54 +0100

Hi!

Analyzing the trends in internet technology, which might be summarized
as 'towards IP everywhere', I arrived at the following statement:

"In a longer timeframe, it makes sense in LANs to incoporate
all layer 2 functionality into layer 3."

Note:
- long timeframe
- talking of LANs, not core networks
- layer 2 will relly be ethernet
- layer 3 will really be IPv6 (I think everybody agrees that this
  won't come for IPv4 :)

Since this is the IPv6 list, I think the people with the most
valuable contributions are here.

First, lets make a list what functionality ethernet layer 2 includes:

A1 - medium access (anyone remembers the good old days of CSMA-CD ? :)
A2 - enable local 'routing' (switching) in networking components
A3 - broadcast service
A4 - multicast service
A5 - addressing at layer 2 is needed for autoconfig protocols
A6 - ARP is included and necessary for layer 3 operation

Note that layer 1 is untouched. There is no better and more cost
eficient method of transmitting frames in LANs than ethernet
right now, and I think also in the future, because it is designed
well and lasting.

Here are the arguments supporting the above statement:

B1 - In the long run, medium access won't be necessary because ethernet
     is evolving into a tree based architecture even in cost sensitive
     areas (e.g. at home) (A1).
B2 - Routing in a LAN close to the end devices is not significantly
     more computing-intensive than switching. Therefore, as computing
     power gets cheaper, it makes sense to build routing-only
     devices (A2).
B3 - Broadcasts are not necessary in IPv6, because we have a far better
     mechanism (service-specific multicast) already incorporated (A3).
B4 - Multicast is also a available in IPv6.
B5 - Autoconifg in IPv4 uses IPv6 broadcast protocols (A5).
B6 - Address resolution (also NDP) would not be necessary any more (A6).
B7 - Office router software will become more simple, because they
     won't need layer 2 any more.
B8 - If the MAC address is included in the IP address anyway, why
     repeat it in the ethernet header? Better save the bandwidth.
B9 - Security is enhanced: ARP cache poisoning is not possible,
     because the plug-and-play protocol introduced into IPv6 to
     propagate addresses would be designed with security in mind.
     Yes, encryption will come, but  ARP cache spamming DoS cannot
     be prevented without modifying ARP. MAC address locking is no
     real solution since the administrative overhead is to high.

The downsides:
C1 - It might really be too early to think about this. However,
     if everybody agrees that it will come, then it might be
     beneficial to design current RFCs with that in mind.
C2 - Simple switches will need redesign to become IPv6 routers.
     That's the price for B7.
C3 - There will be poblems if the transition strategy is poorly
     designed. Since ethernet chips today don't insist on sending
     ethernet headers, seamless transition should be possible.
C4 - VLANs would be a problem if the flowlabel could not be used
     for it.

I want to collect pros and especially the cons (since a have so few)
for this statement, technical and political, so don't hesitate to
express them, either via the list or personal. I'll summarize.

Also, pointers to other mailing lists or other information resources
would be greatly appreciated.

Merry christmas,
Walter
--
Fraunhofer-Einrichtung Systeme der Kommunikationstechnik (ESK)

Walter Zimmer                    Hansastrasse 32
Dipl.-Inf.                       D-80686 Munich
                                 Telefon:  +49(0)89-547088-344
[email-masked]  Telefax:  +49(0)89-547088-221
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------