Date: 14 Mar 2001 19:55:12 -0500 From: Lowell Gilbert <lowell@world.std.com> To: freebsd-questions@freebsd.org, davep@afterswish.com (David Preece) Subject: Re: Adding route using mac address Message-ID: <448zm7onpr.fsf@lowellg.ne.mediaone.net> In-Reply-To: davep@afterswish.com's message of "14 Mar 2001 21:08:17 %2B0100" References: <44ae6odui3.fsf@lowellg.ne.mediaone.net> <5.0.2.1.1.20010315085251.02281748@pop3.paradise.net.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
davep@afterswish.com (David Preece) writes:
> At 14:24 14/03/2001 -0500, you wrote:
> >amour@bugs.elitsat.net (Alexander) writes:
> >
> > > How can I add route for host using the mac address.
> >
> >You can't. Routes have nothing to do with media layer information.
>
> Okay, I realise I'm on shaky ground here, but would like to disagree.
You're squarely in my main field of expertise here, and although it's
a somewhat esoteric point by the standards of most implementations,
I don't think I'm going overboard by saying flatly that you're wrong.
> Routes - next hop ones at least - have everything to do with layer 2. Say
> my machine is 1.2.3.8 on a class C, and my default router is 1.2.3.1. What
> we are effectively saying here is that I am layer 2 connected to
> 1.2.3.everything, and that if I want to get a packet outside of that I have
> to use the machine at 1.2.3.1. So when a packet goes off to 3.4.5.6, on
> layer 2 the packet is addressed over to the router.
"Layer". To borrow a line from "The Princess Bride," you keep using
that word, but I don't think you know what it means. The way you use
OSI terms to refer to IP concepts, even though they don't quite map
cleanly ("layer 2" is not precisely equivalent to "MAC layer") just
strengthens my suspicion. Using the archaic term "class C" just ticks
off one of my pet peeves.
Your example is a perfectly good one, and aside from my pedantic
dislike of your terminology, nothing in the above quoted paragraph is
incorrect. I'll use the same example later on.
> Conceptually it may be truer to describe a default route in terms of mac
> address. "The route out of the layer 2 network is at this address".
> However, it would be a pain in the arse, so we give routers an IP address
> and rely on arp to convert it to a mac address for us.
No. You are breaking the IP layering model completely. The network
layer (at which IP operates) *does* *not* know MAC addresses. At all.
This is an important point, because it is what allows the *same* IP
layer code to easily work with many different kinds of physical media.
A IP route is actually defined strictly at the IP level. On a
detailed level, it consists of a set of destination (IP) addresses, a
next-hop (IP) address, and an interface to send over.
The "set of destination addresses" is the address and netmask of a
network that can be reached, the interface is an abstraction that sits
between the IP layer and the MAC layer, and the next-hop address
belongs to another host which is (assuming everything is set up
correctly) both closer to the destination network and directly
reachable by that interface.
Thus, a route consists of a database 4-tuple: destination address,
destination netmask, the next-hop IP address, and the interface
through which the destination network can be reached. [The first two,
obviously, are the database key.] None of this is MAC information,
because it's independent of the physical media, and in fact different
interfaces may well have different physical media, and yet still have
routes in this same table. [For completeness, I'll note that the next
hop's IP address may not exist -- the link may be unnumbered -- but
that the IP code doesn't need to know this.]
We go back to the earlier example:
> Routes - next hop ones at least - have everything to do with layer 2. Say
> my machine is 1.2.3.8 on a class C, and my default router is 1.2.3.1. What
> we are effectively saying here is that I am layer 2 connected to
> 1.2.3.everything, and that if I want to get a packet outside of that I have
> to use the machine at 1.2.3.1. So when a packet goes off to 3.4.5.6, on
> layer 2 the packet is addressed over to the router.
In that last sentence, the two phrases are occurring at different
levels, not (as the wording implies) the same time. It's true that at
the MAC layer, the packet is addressed to the MAC address of 1.2.3.1,
but the IP layer doesn't know that -- and can't, without changing the
IP forwarding code for every new media type you add.
What happens in forwarding an IP packet is that the destination
address (3.4.5.6) is extracted from the packet, and looked up against
the database, using a longest-prefix match. In this case, apparently
you're assuming it matches a default route, which essentially means
that the longest prefix to match will be zero bits long. The
resulting entry gives the IP address of the router, 1.2.3.1, and the
machine's interface onto the LAN which it shares with that router.
The IP forwarding code then hands the packet to the interface, along
with the next-hop address, and in the Ethernet example, the interface
uses ARP to determine the MAC-layer information to tag on the packet
header.
> > > Because on the LAN some ppl are changing IPs to skip the traffic counters
> > > for them.
>
> Oh. This isn't really a routing question then. Perhaps go to a dhcp network
> and set up the dhcpd.config (or whatever it's called) with very very long
> leases so everyone gets the same IP every time. Hmmm, no, I guess that
> wouldn't help.
Right. If they're already changing their IP addresses by hand, every
OS I know will let them do so whether a DHCP server is around or not.
DHCP does absolutely nothing to keep unauthorized machines off your
LAN.
> Perhaps we need a mac layer accounting daemon that could sit off a tee
> socket. This wouldn't be too hard, and yes, I might be volunteering. Is
> this something the community in general might find useful?
Quite possibly, although it would be worth surveying the state of the
art first; certainly a lot of bandwidth monitoring tools will turn up
this kind of abuse as a side effect of their main purpose. The
original poster seemed to be using such a tool already, which was what
they were trying to evade, so for his purpose it might be easier to
see if that tool can track address usage, or even try another that
can. Or my other suggestion, of hard-wiring the ARP entries in the
router, so that the guilty parties' MAC addresses won't be *useful*
with other IP addresses.
> >You should also, in my opinion, consider non-technical solutions, like
> >terminating these people's accounts, firing them, failing them in your
> >course, slapping their wrists with #6 linguine, whatever's appropriate
> >in your environment.
>
> Might also prove appropriate. However, you're still facing the ultimate
> problem of catching the bastards.
In theory, yes. In practice, this isn't much of a problem. After
all, he already knows this is happening; he probably has reason for
thinking so. Occasionally, it *is* a problem, but that generally
involves people changing their MAC addresses as well, and you can't
detect that without securing the link itself in some way. This is,
for example, the point behind managed Ethernet switches which let you
lock addresses to a particular port.
> Perhaps we need something that just
> correlates mac addresses to IP's? Maybe just leaving running for 24hrs off
> a bpf then compare the answers to what you should've seen.
Yep. Generally this is all that's needed. A lot of these kinds of
cases have been turned up by no more than a tcpdump process output
piped through grep.
Be well.
Lowell
--
Common sense is the collection of prejudices acquired by age eighteen.
-- Albert Einstein
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?448zm7onpr.fsf>