Re: [lwip-users] How to build a simple TCP [...]

[David Empson]

Bob McConnell wrote:
> Kieran Mansley wrote:
> > Simon Goldschmidt wrote:
> > > Is this something to be afraid of? I didn't think the win32 port
> > > would be used in production environments where this matters... But
> > > of course we could change this to be defined somwhere instead of
> > > calculating it from the real ethernet card's MAC.
> >
> > I think that would be better.  It would make it more obvious that the
> > MAC address being used is just made up, and so needs to be carefully
> > chosen.
>
> The specs also say that there are some bits in the first two bytes of
> the MAC that need to be set when it is a virtual NIC instead of a real
> card. I have implemented that at work for emulations using tap devices
> on FreeBSD, but don't have the reference here at home.

The second bit transmitted in the first octet of the MAC address identifies 
the address as "locally administered".

This corresponds to a value of 02 in the first octet when it is written in 
the usual MSB first order, so an example of a locally administered address 
would be 02-01-02-03-04-05.

The first octet can have any even value (bit 0 must not be set, because that 
would identify it as a group address, i.e. broadcast/multicast). The other 
five octets can be anything.

http://standards.ieee.org/regauth/groupmac/tutorial.html
http://en.wikipedia.org/wiki/MAC_address

A locally administered address cannot be allocated by a manufacturer to any 
production Ethernet hardware, but can be used by network administrators to 
assign arbitrary MAC addresses for use within their organisation.

Since locally administered MAC addresses are potentially being reused by 
multiple people, if LWIP picks an arbitrary one it may have a greater chance 
of encountering a conflict. If LWIP "borrows" an arbitrary universally 
administered MAC address, there can be only one conflicting device in the 
whole world.

I suggest using a locally administered address anyway, but it should be well 
commented to explain the potential for a conflict, and summarise the rules 
for allocating a different MAC address, in particular not to use an odd 
value for the first octet (broadcast/multicast).