Summary: MAC addressing in SUN - RFC compliance

From: Alan Arolovitch - Software Support (
Date: Tue Apr 01 1997 - 06:30:20 CST

this forum has been very helpful and responsive as ever.
Original question:

>i wonder if anyone could help me out with the following:
>it's been official policy of Sun to assign identical ethernet
>address burnt in NVRAM for *all* network interfaces.
>Sun does not support two interfaces of the same box on one physical
>segment, therefore it has never been a problem before, but now
>with ATM VLAN one of our customers ran into situation when two
>network interfaces of the same box (ergo 2 identical MAC addresses)
>were plugged into the same ATM switch.
>understandably ATM switch otgether with the customer went crazy.
>after some months of hit-and-miss they zeroed on the problem,
>we advised custom change of ethernet address as per official Sun
>recommendation and the dust settled.
>however the question left whether such behavior is RFC-compliant or
>rather each interface must be assigned unique address, and if
>such is indeed non-compliant, as per client's claim what are the
>reasons for such design?
>was Sun just too lazy to design a proper ethernet driver? ;)

The consensus was:
Sun does the Standard Thing.

Danny Johnson <>
Brion Leary <>
referred me to Sun-Managers FAQ
(my mom told me to RTFM, and i didn't listen ;):

> The Ethernet version 2.0 specification (November 1982) states:
> The physical address of each station is set by network
> management to a unique value associated with the station,
> and distinct from the address of any other station on any
> Ethernet. The setting of the station's physical address
> by network management allows multiple multiple data link
> controllers connected to a single station to respond to
> the same physical address.

  I digged up full reference of the specs:
  [The Ethernet: A Local Area Network, Data Link Layer and
  Physical Layer Specification, Version 2.0 (Digital Equipment
  Corporation, Intel Corporation, and Xerox Corporation,
  DEC document No. AA-K759B-TK, November 1982).]
  The document is not available on the net, so ones interested in
  receiving it may need to call up Digital and request it.

  It's also incorrect to refer to RFC compliance or non-compliance
  here - RFC state only how IP datagrams are to be transmitted over
  Ethernet media, define ARP protocol etc.
  The fine isssues like address allocation are stipulated in Ethernet
  specs, IEEE 802.3 or EthernetII and RFC rely on them.

Further on Casper Dik <casper@holland.Sun.COM> pointed out that
original routing protocols imply one ethernet address per node,
and most probably the common illusion of "MAC address per ethernet
card" is due to the fact that PCs do not have ethernet address and
optional ethernet cards came with unique MAC address on each.
He also suggested to use locally administered Ethernet addresses
range for multi-homed boxes:
2:x:x:x:x:x (second bit of first octet needs to be set)

(is this really one person?! Casper, i can't believe it ;)

The other question is whether that's the Right Thing To Do.
In the era of switched & atm networks this implementation decision
may be more than just a bother, as Brett Lymn <>
justly pointed out.
IMHO, Sun needs to provide at least an option to change this
default behavior. Indeed there's NVRAM environment variable
"local-mac-address?" which defaults to false and is supposed to
be just this switch. However it's been said that its usage is
reserved right now, and there are many cases where its activation
just breaks ARP apart.
So I'll wait for official Sun's answers on projected treatment of the
issue and meanwhile one is to hack /etc/init.d/rootusr.
Brett suggested rather neat way to do it - using
/etc/ethers.<interface_name> for storing ethernet addresses per

Thanks go to:
Andrew Mellanby <> (Danny Johnson)
Brion Leary <>
Casper Dik <casper@holland.Sun.COM> (Kevin Sheehan {Consulting Poster Child}) (Brett Lymn)


Alan Arolovitch, SE				<>
E&M Computing Ltd., Authorized Sun Reseller	<>

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:49 CDT