On Thu, 27 Jan 2011 11:03:41 -0500 Jared Mauch <jared@puck.nether.net> wrote:
On Jan 27, 2011, at 10:04 AM, Owen DeLong wrote:
On Jan 27, 2011, at 6:49 AM, Jared Mauch wrote:
On Jan 26, 2011, at 8:33 PM, Owen DeLong wrote:
I'd like to see IPv4 go away in ~3 years. Any faster would be too traumatic. I think 6 years is a perfectly reasonable time frame. I think if it takes 11 years it will be because of significant foot-dragging by some key organizations. I'm not convinced that foot-dragging is as likely as some people are, but, there's enough probability to provide some wiggle room in the numbers.
I expect that in ~3 years, we will see dual-stack and /64's handed out in conjunction with an IPv4 address as "common".
The ipv6 zealots talking about anything but a /64 for end-site are talking about a "business class" service. Even with my static IPs at home, I have no need for more than a single /64 to be used in my wildest dreams. I could live with ~256 ips for the future. I consider my tech density "above-average".
- Jared
As one of the IPv6 zealots talking about anything but a /64 for end sites, I can assure you that I am talking about it for residential class service not business class.
Your tech density may be above average for today, but, you lack vision for the future.
Imagine a future where devices form autonomous network segments and negotiate prefixes and routing for those segments in a semi- or fully- autonomous fashion.
The appliance net in the kitchen will be managed by a router. The RFID tags on the products in your fridge and your pantries will form autnonous subnets with routers embedded in the fridge and pantries. Each of your home entertainment clusters will likely form its own subnet.
Even today, it is not uncommon for a residential gateway to support at least five segments:
1. External WAN segment shared with ISP 2. Internal wired network 3. Internal wireless network 4. "DMZ" segment 5. Guest wireless network
Seriously, it's important that we do not limit our IPv6 thinking by our IPv4 mindset. The future is not the present and we will see much more advanced capabilities in the residential world going forward if we allow it to happen.
I'm not. There's certainly interesting use cases of this "IP" header type, independent of being v4 or v6.
You're talking about the various segments, and I'm thinking about the folks from Toyota doing their ipv6 local networks integrated into vehicles. But many people are also stuck in thinking that these people need to be segmented in the first place. This "security by obscurity" mentality that being behind a VPN, being air-gapped, wired, wireless, that you are deserving of a variable class of service is part of the discussion.
I could call out vendors that have highly sensitive data that is available "if only" you brought a cat5 cable to the office vs using their "guest" wireless. that segmentation ignores the authentication of end-stations, or person behind the keyboard. If you actually did that, you don't need to have a different 'guest' wireless vs the 'internal' wireless network.
Now, I don't think that by reading this that an enterprise is going to clean up their act, (wired vs wireless), or stop any other silly practices using these "packet eating" firewall/nat/vpn devices.
But tying those practices in to the equation can serve to validate the premise that these people actually need to be segmented vs solving the real security (trust) problem that exists on the end devices. You don't necessarily need to see my AppleTV on my home network, but as a guest at my home, (after authenticating to my local wireless network) you gain access to play music and control various elements of my network. I don't need to make these "public", but if they are on a public-IP, the devices should be able to be properly secured (and can be).
I don't think I need a public and private FridgeNet to determine the quantity and quality of the beverages and offer different SLAs based on if they are on the 'guestFridgeNet' vs 'privateFridgeNet'. This is taking it a step or three too far. Most people don't know or care what their IP subnet is. Even if every time I connected a device to my network (or re-connected after power saving, etc) I incremented the usable part of my /64, it would take me some time to consume that space fully.
I do think we're closer together than apart, but for 90% of home users, (and you can quote me on this in 10 years) a /64 will be sufficient for their uses. Anyone needing more than a /64 for their home is either going to some impractical extreme or better defined as a "prosumer" that will want a higher SLA in the first place, and therefore should pay a modest amount more. '
I think you need to review what subnets originally and are still essential for - overcome link layer framing differences - isolate broadcast or multicast traffic from nodes that aren't interested in it or even the act of ignoring that type of traffic is unacceptably resource intensive for those types of nodes I agree with your comments about security shouldn't rely on addressing. My preferred model would be something like the bluetooth pairing model (i.e. trusted assocations) with time limit on the trust. Even then, it isn't really the machines you can't trust, it's the people behind them, and those people aren't bound to certain select machines. Subnets became security domain boundaries because (a) hosts didn't used to have any sort of firewalling capabilities, where as routers did (i.e. ACLs) and (b) hosts tended to naturally be grouped together based on where security domains would occur e.g. all of H.R.s PCs were attached to the same subnet as all those staff existed on the same building floor or area. However, even if an addressing agnostic host security association mechanisms emerges, we still have an interim period until then where security or policy by subnet is necessary, and we'll also have reasons to subnet after then - the original and same reasons why routers were invented and bridges couldn't do the job. Regards, mark.