Cable Modem [really responsible engineering]

Cross posting sucks. However, this is a special case as this
discussion really ought to move to NANOG without losing context.
Please edit headers to make sure replies go *only* to NANOG.


> There are three reasons that one needs to be able to map an IP->MAC->
> particular customer: 1) to provide customer support, 2) to provide
> network metrics and monitoring, 3) to provide identification in court
> cases.
> If one builds a network that does not provide these three abilities,
> the public will eventually step in -- via the legislature, the courts or
> the marketplace.
> If you can explain how you can provide quality customer support
> without a MAC map, provide network metrics and monitoring without a
> MAC map, and satisfy the courts without a MAC map, then I agree with
> you, there are valid different ways to provide this service.
> However, if you can't meet the three criteria, then the only valid
> design for a public network is one that can track
> is an invalid way to build a public network. It is wrong.


Let me try to rephrase this a bit: to achieve the three goals that you
mention (customer support, network metrics and monitoring, and legal
identification of users) you assert that the way to do so is to have a
mapping between IP address and MAC address. I don't disagree that an
association between IP and MAC can be useful in achieving those goals, but I
do disagree that it is the only one.

I think we are in violent agreement. I don't like the
IP->MAC->Customer mapping, it is forgeable, but it is the only one I
know we have available. I agree with you that it is not the only
possible mapping. If you can point me to a better existing mechanism,
I would be greatful.

My complaint is with people who could collect and use this
information, but then throw it away and claim ignorance when their
network is used to as a springboard for attacking other systems.

Other perfectly valid associations include a non-volatile system serial
number of some sort, the "universal user identification" proposed by Intel,
or some algorithmic generation of an identifier based on physical system
characteristics in place of the MAC address.

I've supported very large client populations and would suggest that it would
have been much more useful to have somehow been able to discern a client's
physical address (for example, 1201 Central Avenue, Room 346) than their MAC
address. MAC address is, of course, useful to distinguish among clients at
the same physical address, but then so would be additional information such
as "port 57, switch 3SW1201SNFC43." The DHCP client and IP stack that we
used did not provide us the luxury of that additional identification,

Sounds like a large company or organization network. Frankly, not
germane to this discussion.

If a database was kept of client MACs, and this information was
required before access to service was made available, you then have a
network of known devices and have made a long step towards towards
assigning responsibility.

Any sort of identifier that helps distinguish among different hardware
classes (as the initial octets of a MAC address identify its manufacturer)
can be crucial in developing a repair history or predictor of failures for
stocking spare parts, but I don't quite see how knowledge of the MAC address
is required to monitor network usage or generate performance metrics that
are not tied to hardware type or specific device: IP address is much more
useful for that, in my opinion, especially if additional information about
physical connections (such as port and switch numbers) is available.

Please remember we are talking about large IP over Ethernet *public*
networks (cable, Etherloop DSL, wireless) which are used by a
completely heterogeneous population. The operator must support the
connection of arbitrary devices. Many of the customers have very
little knowledge of their configuration or networking. The network
operator must support arbitrary devices and clueless customers.

Some scenarios:

1) When a customer calls and reports a connection problem, many times
   the problem will occur before an IP is assigned. The MAC address
   is the only mechanism for debugging these problems.

2) When a customer's device is misbehaving, by slamming a DHCP server
   with many uncompleted requests, by broadcasting traffic, or by
   being hijacked for a DDOS, the only current method of identifying
   the device is through the MAC address.

3) ARIN has sent the strong message that they expect IP over E public
   network providers to use dynamic IP allocation in order to conserve
   IPv4 addresses. Public networks are oversold and a fundamental
   financial/quality requirement is that the rate of oversell can be
   accurately tracked, or that customers be accurately charged for
   their bandwidth usage. In gathering these statistics, a MAC
   address is a key bit of glue allowing one to tie flows to

Finally, I would not want to declare under oath that a MAC address
absolutely and uniquely identified a client host: it's just too easy to

Total and absolute agreement. There is no question that it is easy
for a technical sophisticated customer to spoof a MAC address. This
fact should always be kept in mind when analysing any information.

However, there are a couple of possibilities for spoofing:

1) An existing, connected and valid MAC is spoofed. In that case, the
   spoofing becomes apparent pretty quickly; duplicate MACs make
   themselves known...

2) A non-existing, non-connected and non-valid MAC is spoofed. In
   that case, someone will have had to put them in the database in
   order to get service. One can then go to that person and ask why
   the spoofed

Having said all of this, I want to be sure you don't misunderstand:
supporting customers, whether there are two or 2 million of them, is
extremely important for any service business. Part of that support includes
administering servers and facilities so that all customers can enjoy the
services without interfering with other customers. So are we really in

Mostly not.

I just don't know how to make the last part of the 3-way association
IP-->MAC-->client work reliably without significant changes in most

Yes, it is difficult to add this functionality after the fact.
However, the original discussion was prompted by a question about the
design of a future network. As others have pointed out, if you start
from the beginning, it is possible to design in the simple capture and
maintenance of IP -> MAC -> customer data. To do otherwise is