Enhanced backwards compatibility discussion

3. Coexistence with Legacy IPv4/3. Coexistence with Legacy IPv4.md

@@ -17,19 +17,25 @@ to support a dual-stacked environment.
 
 Before describing the specific techniques for IPv6/IPv4 coexistence --
 dual stacks, tunnels, and translators -- it is useful to answer a basic
-question that newcomers sometimes have: *Why isn't IPv6 backwards
-compatible with IPv4?* The answer is quite simple: this is a
+question that newcomers sometimes have: _Why isn't IPv6 backwards
+compatible with IPv4?_ The answer is quite simple: this is a
 mathematical impossibility. IPv4 contains no provision for any address
 length other than 32 bits. Stretching the address length by only one
 bit, let alone by 32 or more bits, would completely break all existing
 IPv4 implementations. Therefore, __backwards compatibility at the IP
-packet level was not a design goal.__ The only solution was a new
-version number, and in 1994, the next free number was 6. (IPv5 was a
-failed experiment.)
+packet level was impossible, so was not a design goal.__ The only
+solution was a new version number, and in 1994, the next free number
+was 6. (IPv5 was a failed experiment.)
 
 Given that fundamental incompatibility, the designers of IPv6 decided to
-meet a number of requirements that IPv4 could never satisfy, and to
-develop a co-existence model from the start. In short, a *dual stack*
+meet a number of requirements that IPv4 could never satisfy. As a result,
+the IP packet header was redesigned in the light of experience. This has
+no impact except on the low-level code that actually processes
+a raw packet.
+
+Another basic decision was to develop a co-existence model from the start,
+since it was clear that a quick transition to a new version of IP
+was unthinkable. In short, a *dual stack*
 originally meant that hosts and routers were able to handle both IPv4
 and IPv6 at the same time. Recently, this simple view of dual stacks has
 been complicated by the introduction of "IPv4 as a service", as