33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
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? On 7/24/10 3:26 PM, IPv3.com wrote:
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 ?
-- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote:
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 On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock <nenolod@systeminplace.net> wrote:
On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote:
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
On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock <nenolod@systeminplace.net> wrote:
On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote:
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.
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) -- http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my advice
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? On Thu, Jul 29, 2010 at 10:31 PM, Tom Limoncelli <tal@whatexit.org> wrote:
On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock <nenolod@systeminplace.net> wrote:
On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote:
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.
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)
-- http://EverythingSysadmin.com -- my blog http://www.TomOnTime.com -- my advice
-- Byron Grobe
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? -- Byron Grobe -- Byron Grobe
On Thu, 29 Jul 2010 23:45:03 EDT, Atticus said:
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.
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. On Thu, Jul 29, 2010 at 11:55 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 29 Jul 2010 23:45:03 EDT, Atticus said:
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.
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. ;)
-- Byron Grobe
On Fri, 30 Jul 2010 00:14:46 EDT, Atticus said:
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?
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...
On Thu, Jul 29, 2010 at 11:38:56PM -0400, Atticus wrote:
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.
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
participants (8)
-
Atticus -
Christopher Morrow -
IPv3.com -
Matthew Palmer -
Steven King -
Tom Limoncelli -
Valdis.Kletnieks＠vt.edu -
William Pitcock