> From: Bob Braden <braden@xxxxxxx>
>>>> IETF should not make it more difficult for the Internet to adapt to
>>>> changing conditions by standardizing protocols that only work in a
>>>> narrow set of conditions
>>> Like ARP?
>> I wasn't around when the ARP decision was made, so I don't know how
>> widely it was realized at the time that the approach was shortsighted.
> This is a strange discussion. Broadcast networks are an important class
> of link layer technologies, and I would say that by any measure ARP was
> a huge technical success. It may well have been responsible for the
> great popularity of Ethernet and its followons. ... I don't understand
> the suggestion that it was "shortsighted".
I suspect they are talking about two things, one of which is true, and one of
which isn't.
The thing that's true is that ARP contains basically zero security. So,
someone who has access to the local shared medium can spoof you - and even if
you're using end-end authentication, they can mount a DoS attack. However, I
should point out that i) fixing this correctly requires one heck of a lot of
work, since it basically involves creation of some sort of authentication
system, and ii) when ARP was defined, the Internet was so small that the
human/design/programming resources simply weren't available to do such a
design.
The thing that's not true is that all sorts of kludges use it (well, it's
true, but it's not ARP's fault). People have taken advantage of the fact that
there's a layer of binding there ("all problems in computer science can be
solved by another layer of indirection") to do a number of things they'd like
to be able to do (e.g. server pools), but which the architecture *as a whole*
is too impoverished to do, because *as a whole* it doesn't have enough
namespaces and/or layers of binding. (I.e. it's a case of "When the only tool
you have is a hammer..." disease.) This is not ARP's fault. When used to do
*only* what it was *intended* to do, ARP is reasonably good, the biggest
problem being the security one mentioned above.
I would also point out that ARP was thought-forward enough to support other
protocol families and/or hardware types - and implementations which supported
that generality (instead of the usual corner-cutting step of hardcoding in
support for IP and Ether) were able to do so *with no code changes*, which
I thought was reasonably impressive.
> ARP also established an important architectural technique.
Now I'm curious, because I can't work out what you're referring to!
Noel
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf