| 1 |
> > What would have been best, could have been done years ago and not cost |
| 2 |
> > lots of money and even more in security breaches and what I meant by |
| 3 |
> > ipv5 and would still be better to switch to even today with everyone |
| 4 |
> > being happy to switch to it is simply ipv4 with more bits for address |
| 5 |
> > space. |
| 6 |
> |
| 7 |
> This should be FAQ entry zero for the IPV6 FAQ... *NO* you can *NOT* |
| 8 |
> add more bits to IPV4, and still have it backwards compatable. It won't |
| 9 |
> work... period... end of story. Every piece of hardware and software |
| 10 |
> that deals with IPV4 has the concept of 32 bits *HARD-CODED* into it. |
| 11 |
> Switching over to IPV4-extended would be just as painfull as switching |
| 12 |
> over to IPV6. |
| 13 |
|
| 14 |
No it would not, the headers would be different. All the hardware would |
| 15 |
have already updated because there would be no bad sides and it would |
| 16 |
have been released something like 15 years ago. But lets not discuss |
| 17 |
them as we would be here for an eternity and there are already whole |
| 18 |
websites dedicated to just that. |
| 19 |
|
| 20 |
I re-iterate it would be worth hardware not being backwards compatible |
| 21 |
again to go to ipv4 with large address space today. |
| 22 |
|
| 23 |
http://www.hackingipv6networks.com/past-trainings/hip2011-hacking-ipv6-networks.pdf |
| 24 |
|
| 25 |
That's just on security. There's a whole bad side to it's functionality |
| 26 |
too. |
| 27 |
|
| 28 |
-- |
| 29 |
_______________________________________________________________________ |
| 30 |
|
| 31 |
'Write programs that do one thing and do it well. Write programs to work |
| 32 |
together. Write programs to handle text streams, because that is a |
| 33 |
universal interface' |
| 34 |
|
| 35 |
(Doug McIlroy) |
| 36 |
_______________________________________________________________________ |
Archives