Bob Hinden writes: > Seth, > > Do I understand correctly, that you are proposing that all hosts, routers, > firewalls, middle boxes, etc. on the Internet, be updated in order to get a > single extra IP address per subnet? Plus then having to deal with the > complexities of mixed implementations for a very long transition period. > > To me this fails the cost benefit analysis.
Hi Bob, thanks for your reply. Yes, we're proposing a change that affects all hosts and routers in order to get an extra address per subnet. As I described in my reply to Derek Fawcus, this change -- unlike some of the other changes we will propose :-) -- has a particularly nice incremental-deployment story due to RFC 4632 and the largely correct existing behavior around it. This is to say that, if you patch your own devices and then deliberately number a host with the lowest address, the rest of the world can already talk to that host under existing standards. (Patching your devices has little cost in functionality to you; you lose only a disused obsolete form of directed broadcast.) In this case, if you don't patch your devices, you can also already talk to anyone else who does; there's no way for you to know! Thus, the biggest benefit of officially standardizing this is to encourage vendors to start changing this behavior now, so that it will be correspondingly more likely that people who care will have fully-patched or sufficiently-patched network segments in the future. With this change, people who don't care or don't know the compatibility details of devices on their local networks can just continue not to assign the lowest address at all. (Conveniently, the networks where a single extra IPv4 address is most valuable are also generally the same networks where it's easiest for the network administrator to know and predict what software is running on the network segment.) While our other proposals don't have these same properties, they also imply much larger numbers of IP addresses becoming available, which might change the cost-benefit comparison. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
