> Have you ever used the term "layer violation", or heard it used by > someone else? Occasionally :) > Having the application know the network layer address is just slightly > worse than having it know what it's Ethernet address is or what port > it is attached to. The flip side to this is that an immense amount of additional complexity is required to truly make applications agnostic of lower layers. "Classic" TCP/IPv4 was a lot simpler and more deployable than it would have been with a genuine ID/LOC split. By making the assumption that an address was "good enough" as an endpoint identifier, made implementation on modest 1980s era hardware, not to mention slow networks, a lot more practical. And in the days before laptops and before the net got big enough to make prefix aggregation necessary, this was a reasonable assumption. It seems that a lot of successful protocols were originally optimized for deployability rather than optimized for longevity. I suspect that those protocols tend to be more successful, even in the long term, than those that are initially optimized for longevity over deployability :) IPv4 is one example, DNS is another, HTTP is a third, I suspect BGP is a fourth, and I'm sure there are many more. > There are a few cases in which it has a real need to know. In all > except those few, believe me, every whine I hear about renumbering is > in my ears a whine about the layer violation. Make it go away, and the > renumbering problem will be *much* easier to solve. Well, every time I hear a whine in IETF about how people "should" or "should not" do things a certain way, I ask myself whether this is really a reflection of the network architecture's failure to solve some important problem. After all, if there were a better way to solve the problem within the bounds of the architecture, people would probably find it sooner or later. Various practices that some of us might label as dubious, including NATs, using IP addresses as authentication tokens, using a single DNS name as a way to name a service that's actually implemented by a large pool of hosts, or layer violations in general, are all attributed to failures of the architecture or failures to implement key features in our core protocols in a timely fashion. So the reason people are writing applications that look at IP addresses is because the network doesn't give them the tools that they need to write good apps without looking at IP addresses. (And they need to do that even more in a NATted environment, or in an environment where hosts have multiple source and/or destination addresses with different characteristics, so it's not like the architecture is moving in a direction to discourage layer violations). It's a bit unrealistic to expect those applications to change in order to solve the renumbering problem, without providing those tools. The incentives all favor solving your own problem (or making your own customers happy) even at the risk of creating a problem for someone else, not to solve someone else's problem even though it makes your own product less functional, efficient, or reliable. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf