Hi Derek, thanks for your comments. Derek Fawcus writes:
> I'd suggest you'd have a hard job making local links safe for on-link > use of the all-0-host address, if only because of the number of routers > deployed (e.g. Cisco boxes, but probably others as wlll) which have that > knowledge hard coded. i.e. they treat them on RX just like the > IPv6 "any router" case, so will not ARP for the target. Yes, that's the common behavior of existing devices. > That said, I already make use of the the subnet all-0 and all-1 host > addresses, but off-link. e.g. as NAT addresses because off link devices > simply can not know where the CIDR boundaries are. I suspect that > is about the best which can be done. Yes, for example if you go to http://ec2-reachability.amazonaws.com/ your client will connect to numerous hosts ending in .0, which in a /24 or smaller would be the lowest addresses in their respective subnets. We can't tell from the outside whether those hosts are actually the lowest addresses (with host and router patches to allow them to be reachable) or whether they are part of a larger-than-/24 subnet in each case and just happen to be ordinary hosts in the middle. As you suggested, RFC 4632 already expects distant hosts ("off-link") not to make assumptions about this. > I'd suggest it wouldn't be safe to hand such out to "normal" hosts, > e.g. by DHCP, but one could envisage some special UDP based services > using the address. In our view, it would be entirely at the discretion of the network administrator, based on his or her knowledge of the local network environment, and we wouldn't suggest that it be a default behavior in a DHCP server configuration as shipped by an OS vendor. For instance, if you told a DHCP server to hand out addresses from 192.168.42.0/24, it would continue to default to not assigning 192.168.42.0 due to uncertainty about whether a device could usefully accept such an assignment. But a network administrator could individually choose to assign it on a particular network where it's clear that all of the devices had been upgraded. This is especially straightforward in a managed hosting environment, which is also where IPv4 addresses are most in demand. In support of this, we have a patch in the Linux kernel, currently included in the 5.14 kernel release candidates, which changes the host and router behavior for Linux routers and hosts to remove the interpretation of the lowest address as a directed broadcast. Clearly, this will be an interoperability problem initially for unpatched devices, so we haven't done anything to make userspace (or users) make use of these addresses. But, as you note, if you know that you're able to do so on a particular network, you can do that right away and it should interoperate with distant hosts today. > So while we could make this change, I suspect it will be a long time > before such all-0-host addresses are generally usable on-link. I agree. A nice thing for this particular proposal is the on-link versus off-link distinction that you mention: here the off-link work was already done for RFC 4632 so if you know that your segment will be OK, you can opt into it. (Note that this is already true now, because nobody on the rest of the Internet can even tell the difference! But right now the IETF standards are calling for implementations _not_ to facilitate this within a link.) More generally, we don't expect our proposals to have an immediate positive effect of achieving global interoperability; there will be no "flag days". The idea is that IETF would first approve some or all of these proposed extensions of the IPv4 protocol, changing the behavior expected of hosts and routers. New releases of existing software (like operating systems) and firmware (like dedicated router software) will then make these small changes. (Some of our proposals, as we'll describe more when we submit our other drafts, are already implemented in major operating systems. One has been enabled for a decade without any ill effects; another for a year, also without ill effects.) We don't expect many people to deliberately install new software or firmware in order to enable these IP protocol changes. Instead, we expect the changes to roll out as part of the usual process of refreshing equipment in the field. Network operators and end-users will gradually install these newer releases, for whatever reason, whether they buy new equipment, upgrade existing OS's, install security updates, etc. The Internet community has done this twice before for CIDR and for IPv6 -- in both cases, piecemeal as software and devices were gradually updated. CIDR and IPv6 edge support took years, and we expect our proposed improvements to take years also. And yet, today, many more operating systems now have automatic over-the-net update mechanisms, which will reduce the manual labor of installing upgrades, in many cases to zero for end-users. Eventually, after years, there will be corner cases in which a particular site may want to use an IP protocol improvement, and finds a needs to upgrade or replace some older equipment merely to enable the protocol improvement throughout their subnet. (We have similar situations today, in which a user may need to upgrade their ancient DSL router before they can participate in IPv6, for example.) But we expect that to be a small minority of situations. Instead, the capabilities will just roll out gradually, until a point when, after years, they become more generally usable than unusable. One could argue, that given the years it would take, it's not worth doing at all. The same wasn't true of CIDR, and it wasn't true of IPv6. Regarding improvements to IPv4 unicast, that argument won the day 13 years ago, when similar ideas were proposed and not accepted (in draft-wilson-class-e and draft-fuller-240space). From the viewpoint of today, we would have been better off if 10 years ago we had said "Go ahead", because if we had, today the protocol improvements would be fully landed and we would be using them. As the saying goes, the best time to plant a tree is 10 years ago, and the second best is now. > It is possible some routers drop off-link packets destined to the > all zero host address not only due to ACLs, but due to the don't > forward directed broadcast behaviour. Assuming you're referring to distant routers that don't have any interfaces on the affected link at all (wrongly assuming that the distant destination address is a directed broadcast when it ends with 8 or more zero bits), there was a NANOG mailing list thread talking about this behavior not long ago. While it's an improper assumption under RFC 4632, it may occur here and there. But we don't think it's particularly common; we ran some tests on RIPE Atlas, for example, to connect to some of the .0 hosts in the EC2 test services mentioned above. They were roughly as reachable as non-.0 hosts. If you're talking about routers that do have an interface on the affected link, they would already not deliver those packets successfully for the reason you mentioned that they wouldn't ARP for them and would instead deliver them -- if at all -- as link-layer broadcasts. > (Note you could also pursue deprecating the all-1-host address being > used as a local broadcast, as 255.255.255.255 can replace most such > on link uses. That would also strike me as a forlone hope). We've also thought about this, and it seems clear, e.g. from IPv6's approach to address scope, that we would have been better off overall with a significantly different broadcast architecture in IPv4 as well. However, we chose to propose deprecating only the all-0s form because it has consistently been described for decades as obsolete, and as existing only for backwards compatibility with systems that no longer exist today, for decades. By contrast, there could be a few real applications using the all-1s form in places, even if there are better alternatives available for it. Our view is that it's wasteful to have two different directed broadcast addresses for a reason long acknowledged as obsolete. Having a directed broadcast concept at all may not have been an ideal choice in retrospect -- certainly RFC 2644 means that it's a lot less useful than was first anticipated, since it came to be abused for denial-of-service attack amplification -- but we're not proposing to eliminate that concept. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
