![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
ned> Nor did I say you could. The point is that how IP addresses are ned> used varies. anthony> My point is that you want to uniquely identify every machine anthony> in the world using IP, then every machine must have a unique anthony> IP address. If you are using names instead of IP addresses, anthony> and you still want to uniquely identify every machine in the anthony> world, then every machine must have a unique name. Anthony doesn't seem to get the difference between requirement for service and implementation, along with not understanding a long list of other things... First, assuming that I (as a user of some service) must reach a particular, unique machine is a geek wish, not a requirement. The folks monitoring and maintaining the machines need to be able to get unambiguously to that machine but that is a great use of 1918 space. Wasting public IP addresses one per machine when there is no requirement seems to violate Anthony's claimed concern about address space. Second, there is no reason that, based on service requirements, I can't choose to either use unique FQDNs *or* unique IP addresses (or both) to meet the uniqueness requirement, assuming that really is necessary. ned> Why is this so hard for you to understand? anthony> I understand it perfectly. What I am illustrating is how anthony> poorly people understand the real problems, how careless they anthony> are when reading, and how readily they confuse one problem anthony> with another. This is why fixed address spaces will be anthony> exhausted, no matter how large they are, and this is why TLD anthony> management will continue to be a mess, no matter what changes anthony> are made. Anthony rails here about waste of fixed address space yet advocates that in order for us to be "pure", we must waste an IP address on every device that we need to identify as "unique" on the Internet. OK, which do you want? Better use of address space or a dictated waste of address space for a dubious technical "need"? -- Paul
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.