Agreed.<br><br>I think also that the time for retrospection is not yet upon us.  The IPv6 transition has recently been gaining steam.  I think once we see some more successful transitions and deployment experiences <i>then</i> we&#39;ll be able to see some of the things that made the successes possible.<br>
<br>After all, having a pile of miscellaneous, possibly incomplete, car parts on the floor does not really tell me how I should have built a car.  Having at least one working car to examine gives me at least one reference point for what parts are needed and how they might go together.  And the more working cars to examine the easier it is to analyze the commons elements to successful automotive manufacturing.<br>
<br><div class="gmail_quote">2009/3/26 Fred Baker <span dir="ltr">&lt;<a href="mailto:fred@cisco.com">fred@cisco.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, I think it is only fair to point out that they didn&#39;t have the option of making it backwards compatible with IPv4; it&#39;s not that they didn&#39;t, it&#39;s that they couldn&#39;t. How, precisely, would you make an IPv4 packet that has longer addresses? IPv4 forces any change to the header to become a new protocol.<br>

<br>
I could imagine making a protocol (IPv17 if you like) that was a different protocol than IPv4 but had a variable length address: for example, it might be a tuple that contained the length of the tuple, the length of the network part, the length of the host part, the network part, and the host part. If the other fields were the same as IPv4, one could imagine deploying the new protocol in such a way that a translator could go between them, and put IPv17 in the backbone. We would be in a position much like we are now, however; from 1995 until now nobody would see a business justification for deployment, and folks who deployed would find that they had a hard time talking with folks who had not. It would be essentially the same issue we face now.<div>
<div></div><div class="h5"><br>
<br>
On Mar 26, 2009, at 2:07 PM, Scott Beuker wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don&#39;t see the point of raking over history.<br>
</blockquote>
<br>
The value would be in recognizing the mistakes that were made and<br>
learning from them in order to avoid making them again. Unfortunately<br>
I don&#39;t see any willingness to take an honest look at the mistakes<br>
that were made, so you&#39;re right, there is no value in rehashing the<br>
history.<br>
</blockquote>
<br>
<br>
Furthermore, I think it&#39;s highly debatable whether the big mistake<br>
was technical (a lack of backwards compatibility), or business (the<br>
industries lack of timely action). Or both.<br>
<br>
It seems to be fashionable this month to point the finger at IPv6 for<br>
having failed us, but dual-stack could have been a solid transition<br>
mechanism if started earlier. But, you know, something about leading<br>
a horse to water and then he doesn&#39;t drink.<br>
<br>
- Scott Beuker<br>
</blockquote>
<br>
</div></div></blockquote></div><br>