<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: CIPE-WIN32 & Bridging
From: Olaf Titz <olaf,AT,bigred,DOT,inka,DOT,de>
Date: Tue, 17 Oct 2000 12:21:24 +0200
In-reply-to: <00b201c0338d$9c8d86e0$0264a8c0@mycity.it>

> I'm currently handling things internally with synthesized MAC information
> in CIPE-Win32, however, I don't know how or if two endpoints should
> actually exchange that information. Is CIPE 1.4 passing the MAC information
> between endpoints now ? Are MAC level broadcasts, etc supported ?

MAC addresses have no meaning as such, and need not be known across
the network.[1] A cipd* (protocol 4) interface does never use its own
MAC address at all; like in the protocol 3 version it simply receives
everything. IOW it behaves like a hardware interface in promiscuous
mode. This implies it does receive broadcasts and multicasts.

The sending side is handled completely by the OS protocol stack. The
first IP packet to be routed to the peer device causes an ARP
query for the peer address (MAC broadcast) to be sent over the
connection. The peer answers with an ARP response (MAC unicast). This
can't fail because the IP addresses are always right (or else the
packet wouldn't have been sent to the CIPE device in the first place,
provided the routing is correct) and the MAC addresses are ignored.

Btw. the MAC addresses must be ensured to be unique. Taking the MAC
address of an existing Ethernet interface will break bridges (it
confuses the STP to have two ports with the same MAC address; the
consequence might be that a port gets mis-identified as redundant by
the STP and disabled when in fact it is not redundant). From current
device.c:

       We use 00-00-5E-vv-nn-zz with
       vv=1pppccc0, p=protocol, c=crypto,
       nn=device number, zz=from MAC of first eth device.

00-00-5E is the vendor prefix assigned to the IANA for IP purposes and
with the highest bit set in the vv byte this doesn't collide with any
current IANA usage (see RFC 1700). The zz byte can still collide,
however.

The Linux PLIP driver uses FC-FC-ip-ip-ip-ip for its MAC address. This
is not covered by the vendor assignments and worse, since interfaces
on one machine may have the same IP address, it is still not
collision-free.

So to be safe the MAC address of the CIPE device ought to be
configurable. But as long as no bridges are involved it can be
ignored.

Olaf

[1] Bridges only know which MAC addresses hang off of each of their
ports. They don't know how exactly they can be reached. Non-bridge
applications don't know their MAC addresses at all, e.g. for IP they
run ARP queries to find them and cache them only a short time.





<< | Thread Index | >> ]    [ << | Date Index | >> ]