[e2e] use of MAC addresses
touch at ISI.EDU
Thu Apr 13 10:39:04 PDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Fahad Dogar wrote:
> On 4/13/06, Joe Touch <touch at isi.edu> wrote:
>> Please explain how ARP and DHCP would then work. Or router discovery and
>> host address assignment in IPv6.
> I agree --- we would require changes to DHCP and probably would not
> require ARP at all. A very naivete alternative to DHCP could be: new
> node generating a random number which acts as its temporary address
> and is used by the DHCP server to assign the IP address. With flash
> memory, writing layer 2 addresses in this manner shouldn't be a
> problem as well.
The problem with 'try and fail' is that these approaches may kill the
link layer, e.g., spanning tree. We already use them at L3 (see RFC
3330), but resolution of conflicts relies on unique L2s.
You still, however, have not explained why unique MAC addresses isn't
sufficient. They're simple, and already widely in use. And they're cheap
- - a great description of how cheap:
- use the serial number of a US dollar bill
- burn the bill
I.e., the upper bound cost is exactly 1 USD.
> IMHO, we have to change these protocols because they have been
> designed keeping in view the presence of MAC addresses and how they
> work. If we were to redesign Internet and networking technologies
> (clean slate approach), do we need to have a different MAC address.
> Shouldn't IP address be sufficient? It is like assigning a globally
> unique name to every person and then asking him to maintain an
> additional name for 'local' identification.
This is one of the biggest problems with the phrase "clean slate". It
does NOT mean that you MUST start with a blank page and throw out
everything FIRST. It means you _can_ redesign any part you NEED to redesign.
As Ted pointed out, you haven't explained the problem with unique MAC
addresses that needs to be solved yet. Once you have that, then you can
erase the slate.
That said, blank slates aren't how we build networks. We start with
ideas, not just empty space. Once you show the need to erase, you have
to have a workable solution as an alternative.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the end2end-interest