[rfc-i] IPv6, was: Re: Does the canonical RFC format need to be "readable" by developers and others?
hallam at gmail.com
Fri Jul 6 08:21:33 PDT 2012
Actually there are ways that IPv6 could have been made to work using
the 32 bit addresses as a starting point. For example we could put all
the networks connected to the Internet behind a NAT box to give us an
effective 32+32 = 64 bit address space.
We could have taken the dark space and turned it into 2^30 net
prefixes for an extended routing scheme.
We could have taken a large number of other design approaches had the
problem of actually deploying IPv6 been taken as a serious issue
rather than an afterthought.
The principle objective for IPv6 was to prevent the OSI folk taking
over. So working was not a major design concern.
On Fri, Jul 6, 2012 at 5:24 AM, Iljitsch van Beijnum <iljitsch at muada.com> wrote:
> On 6 Jul 2012, at 1:44 , Martin Rex wrote:
>> The IPv6 folks IMO did not sufficiently think through what they were doing,
>> and created a big mess. Had they taken a more conservative approach,
>> the whole world would be better of today. But instead, they created the
>> current mess, leaving us with having to implement, support and required
>> to transparently run on two entirely seperate internets for at least
>> 20 more years.
> Tell me then how to shoehorn 128 bits into a 32-bit field?
> There is no way to make IPv4 work with addresses longer than 32 bits, therefore IPv6 could only be incompatible. Also, it was good to leave all the IPv4 limitations behind. Just look at ethernet, which is now running at 100 Gbps with 1500-byte packets = (at least) 8 million forwarding table lookups per second, because obviously you want to be compatible with those old NE2000 cards.
> However, I can agree that there was too much push for dual stack and not enough for translation. Dual stack doesn't solve anything and is therefore unattractive. But being able to move to IPv6 for your own network while the rest of the world is still on IPv4 is very useful.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest