33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
As some people (who understand IPv4) know, there is a SINGLE
spare/unused bit in the IPv4 header that can be set to 0 or 1.
Some religions require that it be set to 0. Adult content is marked with a 1.
That single bit can be viewed as common between the Source and
Destination creating a 33rd bit of addressing.
Since it is a single bit, it is welded together for both Source and
Destination. 0-Normal 1-Evil/Other/Adult/XXX
In anticipation of expanding to 33-bit addressing, another bit was
deprecated years ago. It can now be used to UNWELD
the EVIL bit. That would allow EVIL to be only for the Source. The
Destination would have its own EVIL bit.
If two bits are used, then the potential to communicate between the
previously welded address spaces arises.
Some enforcement could still be used in Edge Network Elements to make
sure both bits are 0 or both 1.
Enforcements are hard to maintain and full 33-bit addressing may emerge.
As an aside, NAT was primarily added to improve the .NET Architecture
with a Flash Upgrade-able Network Element.
It is a shame that IPv6 salesman do not seem to understand
"Architecture". They continue on the [NAT is Evil] path.
NANOG can play an important role in shaping how Address Plans for
North America evolve. Since Network Elements
are going to be flash upgraded for the new DNS, it is easy to (unweld/change)
the 33-bit addressing for .XXX
The 33-bit addressing works into the 66-bit Triple-Tagged VLAN
addressing with Content Rating.
http://en.wikipedia.org/wiki/IEEE_802.1Q
The Locator is 33-bits and the ID is 33-bits. Both are UNIQUE. Both
fit in the IPv4 foot-print.
The three-ring circus architecture emerges. (((Core)Edge)Fringe)
does NANOG care? is NANOG now Fringe ?
I am very curious to see how this would play with networks that
wouldn't support such a technology. How would you ensure communication
between a network that supported 33-Bit addressing and one that doesn't?
33-bit is a fucking retarded choice for any addressing scheme as it's
neither byte nor nibble-aligned. Infact, the 33rd bit would ensure that
an IPv4 header had to have 5 byte addresses.
William
isn't ipv3.com@gmail.com jim fleming?
<http://www.ietf.org/mail-archive/web/ietf/current/msg04279.html>
(for reference)
pls to not be replying to the list when ipv3.com posts to nanog..
-Chris
33 bits nearly as useful as my proposal to extend the live of IPv4 by
simply using the unused addresses. What "unused addresses" do I speak
of? Currently the highest IP address is 255.255.255.255. Well, why
not use the addresses from 256 to 999? IP addresses could go all the
way to 999.999.999.999 and still be 3-digits per octet.
We wouldn't even have to modify much code. How many times have you
see a perl script that uses \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} as the
regular expression for matching IP addresses? Tons of code assumes 3
digits per octet. None of that would have to change.
We can get a few more bits another way. Why not steal bits from the
port number? We used to think we needed 64k different ports.
However, now we really only need port 80. Instant Message tunnels
over port 80, so does nearly every important new protocol. Why not
just reclaim those bits and use them for addresses? Instant address
extension!
Tom
<<<--- indicates humor or sarcasm (in case you weren't sure)
What world do live in? Yes, we extend the life of IPv4 by increasing the
numeric range. As for "only needing port 80", I'm not really sure where
you've been for the last decade or so. There's are hundreds of services
using different ports, and tunneling them all makes absolutely no sense.
Yes, we don't really need 65k ports, but stealing bits in the header from
them is the most ridiculous thing I've heard yet.
List of registered ports: http://www.iana.org/assignments/port-numbers
<http://www.iana.org/assignments/port-numbers>Also take into account public
access *nix servers, with people running their own services on whatever port
they've taken or been assigned. How do you intend to implement a solution
for that? Give public access servers the middle finger and keep on going?
What world do live in? Yes, we extend the life of IPv4 by increasing the
numeric range. As for "only needing port 80", I'm not really sure where
you've been for the last decade or so. There's are hundreds of services
using different ports, and tunneling them all makes absolutely no sense.
Yes, we don't really need 65k ports, but stealing bits in the header from
them is the most ridiculous thing I've heard yet.
List of registered ports: http://www.iana.org/assignments/port-numbers
<http://www.iana.org/assignments/port-numbers>Also take into account public
access *nix servers, with people running their own services on whatever port
they've taken or been assigned. How do you intend to implement a solution
for that? Give public access servers the middle finger and keep on going?
I hate to say this, but all of you who are actually thinking about stealing
bits from IPv4 headers when IPv6 is already here: Look who started the "ONE bit
or TWO bits" thread. YHBT. HAND. 
I (unfortunately) cannot get native IPv6 from my ISP at this time, but do
have several tunnels set up using Hurricane Electric's excellent tunnel
brokerage service. All my local systems are dual-stack, my public access
server has a routed /48 that I use to broker my own tunnels for devices
(like my Motorola Droid cell phone). IPv6 is the future, and it is coming.
As Valdis said, why try to extend the life of an effectively dead
technology, and an inferior one at that. With IPSec compliance integrated
into the protocol itself, and the hundreds of other benefits, why try to
morph an old technology? In with the new, out with the old. IPv4 is very
soon to be a completely dead beast, and we'll be all the better for it. This
is the age of the internet, everything is interconnected. There is no
possible way for v4 to keep up with the growth of this era.
You *do* realize that IPv6 IPSec is the *exact same stuff* that's in IPv4, the
only difference is that a "compliant" IPv6 stack has to include it, as opposed
to the optional-but-all-major-OS-do-it status in IPv4, right?
Does anybody know of *any* products that support dual-stack and include
the IPv6 IPSec stuff but left the IPv4 IPSec stuff out? I've never actually seen one...
Fark, Tom, he's gone straight past the hook, line, and sinker, and taken it
all the way up to the second line guide. Better get the big pliers.
- Matt