Most RFCs are deeply technical — and they follow the “Yaakov rule” for intelligibility (if you didn’t write it, or you didn’t sit with one of the authors in a bar someplace to talk about it, you can’t understand it), there are a few here and there every network engineer should know. RFC 6250 is one of those. Titled “Evolution of the IP Model,” this RFC covers the baseline assumptions around IP networks when IP was designed, versus the real world of IP networks today.
Some of this RFC you’ll find to be common sense, other parts something you’ve not thought about before, and other parts — you’ll probably disagree with (where two are more agree on everything, one of them is redundant). Let’s highlight a few of the claims, the replies to those claims, and then some thoughts about those replies…
Links and Subnets — The authors spend just a short period of time discussing the difference between a “link” and a “subnet.” Readers mostly familiar with Ethernet might find the definitions they provide — a link is the area within which an IP packet can be forwarded without decrementing the TTL, a subnet is the set of hosts assigned addressed from within an IP subnet — a little confusing. The world used to be much messier in this regard, particularly in the area of nonboradcast mutli-access (NBMA) links. We don’t have as many of these today, so the difference doesn’t seem as crucial. You will still hit these in overlay networks from time to time, particularly in DMVPN and other technologies of this sort. What’s really useful here, though, is a reminder that in IPv6, links and subnets are not at all the same thing.
Claim: Error messages can be received in response to data packets — This is a huge deal in today’s networking world — not only across the Internet, but also across a local network. The idea that error messages can, and will, be received for any particular condition, from explicit notification to host unreachable, is just not something you can, or should count on. This has a major impact on application developers as well as network engineers troubleshooting a network. If you need error messages of any sort to be delivered, you’d better design the network to support them explicitly. By the way, one of the reasons these messages are difficult to deliver is because connectivity in the Internet is neither symmetric nor transitive any longer.
Claim: Multicast is supported within a link — We always seem to assume you can send a multicast across a single link; for instance, when troubleshooting it’s easy to ping 126.96.36.199 to see if EIGRP multicast packets are getting through. But a failed ping to a local multicast address doesn’t mean the link isn’t working correctly. This is, again, common in NBMA networks; you never can tell what the transport you’re working with actually looks like. Just because it says it’s an Ethernet interface doesn’t mean it is, in fact, an Ethernet interface.
Claim: Multicast/broadcast is less expensive than replicated unicast — We always assume that replicating multicast or broadcast across an Ethernet segment is cheaper than sending multiple unicast streams across the network, but this simply isn’t true. Particularly when you start dealing with layer 2 overlays on top of layer 3 networks being used as a data center fabric, all bets are off as to which method is cheaper to implement. A lot of it going to depend on the number of receivers, and the amount of the fabric being covered, as well as the intelligence of the control plane. But in general, the more sparse the receiver set, the more sense it’s going to make to have the transmitter bear the burden of replication by sending multiple unicast streams.
These examples give you a flavor of what’s in this RFC — solid, practical wisdom, for the most part, from engineers who have lived with IP for a number of years, and seen the protocol and the model surrounding the protocol through the large number of modifications made to it across those years.