IPv6 Network Administration

Resiliency

By resiliency, we mean two things.

First, consider an average network. At any given time, there may be various adverse conditions present. These conditions may be environmental, inherent or of some other form. Regardless of these, IPv4 can often continue to work. For example, network congestion, error-prone lines, memory overload, and so on, are all problems IPv4 has proven able to cope with.

Second, the specification for IPv4 is written in such a manner that it admits of "reasonably" coherent definition, and can be implemented in a finite amount of time, by a finite number of people, for a finite amount of money. Not all networking standards have had such felicitous specifications. It's a real testimony to the robustness of IPv4 that the stack has made it into an incredible array of computing equipment, and particularly into embedded systems, tiny machines with barely a single kilobyte to spare that somehow squeeze in a full IPv4 stack. Indeed, if IPv4 had an overly vague specification, the economics of embedded systems would have made it impossible to produce embedded devices supporting IPv4.^[3]

Accordingly, in IPv6, we would like for the specification to be coherent, complete, and not contain any hidden "gotchas" that only emerge under unusual circumstances, such as heavy load or limited memory availability.

^[3] With embedded systems, you usually only get one chance to get something right. If the system contains an error, replacing it will frequently not be an option. ...