Networking

I think the biggest change is getting out of the NAT mindset. IPv6
restores the original end-to-end nature of the Internet.

How much you want to bet that residential access providers will continue to charge extra $ for more than one IPv6 address, continue to assign dynamic addresses, etc -- just to create an artificially tiered service?

Theydll switch it to a change request fee.

Ideally you're going to get a /64 which is what the designers intended, but even handing those out on a dynamic basis could be annoying. Can you imagine a routine change of your provider-assigned address renumbering your entire internal network? If they do that, I'd rather be assigned a single /128 for my firewall and run NAT66.

Seems more likely that your home network might just get bridged onto the provider's cable plant, so their whole network in your neighborhood looks like one big Ethernet segment.

Acecape does something similar with IPv4 on their DSL circuits. They give you an address on a /24 but it's restricted somehow at the DSLAM so that you can't use an unassigned address or exchange packets with anyone on that subnet other than the default gateway. If you sniff it, though, you see lots of ARP going over the wire.

Scoping a /64 across an entire "node" (~500 subscribers for cable, 32 subscribers for PON, and for DSL it would probably be whatever the line capacity of a single DSLAM is) seems to make sense from a capacity planning point of view, *if* they could find a way to keep neighbors from stepping on each other too much. At first it seems feasible to simply restrict intra-node traffic at layer 2, until you consider that it's perfectly reasonable that neighbors might want to Skype or play online games with each other, etc.

Perhaps it would be sufficient to restrict *broadcast* traffic at the demarc (in the cable/DSL modem or ONT, or even in a consumer grade IPv6-ready firewall) so that traffic flows freely but neighbors don't end up in one big "network neighborhood" when they bring their computers online. Or if we're going to return to the good old days of firewalls that just do filtering and not NAT, then a properly configured consumer-grade firewall would simply drop all inbound packets that are not known to be part of an existing flow -- but it would have to do it without routing.

On the other hand, one would think that The Man would very much like to have static IPv6 down to the device level for tracking purposes. MPAA/RIAA types would enjoy it. "Law" enforcement types would have an easier time nailing people for non-crimes. And the folks who sell your information would be able to tell the difference between traffic originating from different computers in the same household.

Right now, I'm sitting on a /23, so I don't see how the situation is fundamentally different than what's already happening: that /23 must be bridged to other local customers.

I'm currently on a /24, and I see lots of hosts are pingable within the subnet.
And it seems that unlike Acecape, Verizon is letting me connect to various open ports on thos hosts.

Interestingly, all of them have the same MAC address. Also, I'm not able to DHCP for more than one IPv4 address at a time. Clearly the equipment on the FiOS network is doing more than just bridging Ethernet between the port on my ONT and an upstream router somewhere. Probably both the ONT and OLT are configured to pass IPv4 through in a specific way.

Doing this effectively with IPv6 would require passing the router advertisements downstream, and then admitting the subscriber's various IPv6 addresses upstream in an orderly fashion while both suppressing inter-subscriber broadcasts and handling the conflicts that are created when two or more morons start hardcoding IPv6 addresses starting at the bottom of the subnet instead of allowing their computers and other devices to derive their IPv6 addresses from the MAC address of each device.

It's all doable -- just a question of how they go about it. It should be interesting. It would be a shame if ISP's took the easy way out. There are a lot of advantages to bringing back the end-to-end nature of the Internet, even from the ISP's point of view. For example, I'm sure that the ones who provide both Internet and Television would love to be able to talk to the various DVR's and other set top boxes without having to resort to stupid router tricks.

And there's really no reason not to let the subscribers have as many IPv6 addresses as they want. It's not as if we're back in 1999 and ISP's are still arguing that NAT violates their ToS because you're connecting multiple endpoints and only paying for one. These days, most of them even *give* you the router.

They do something similar here in Stockholm. The city has a fiber backbone that all the ISPs sell subscriptions to.
Some allow edge-premise routing-switching while others require one arm routing back at the internet handoff.
I personally think having the ability to communicate with peers unrestricted will be a good thing and bring
people closer to one another in the same communities.

Oh how I wish I understood this all.

Some of us work in the ISP industry :)

And some of us work in the networking equipment industry. :)

will become common for hosts to automatically register themselves with

nameservers, and we will have come full circle.

Ahhh but which one is better?

The fat client / thin client circle has now gone around one and a half times, and different people will tell you one or the other is better. It also might be that the registering-yourself thing worked well in small networks but doesn't work well at the internet level for some as yet unforseen reason.

you imagine a routine change of your provider-assigned address
renumbering your entire internal network? If they do that, I'd rather

be assigned a single /128 for my firewall and run NAT66.

Okay, maybe my as-yet-unforseen problem has already been forseen.

Some of us are programmers who don't trust their network department so had to learn a few of the more simple things about networking.

But then how do you refer to your machine from the open net?
Is everybody going to start being universe.galaxy.westernspiralarm.whatexactlyiswestwhenyourereferringtothegalax y.unfashionableend.earth.us.ny.mtkisco.me

That's a hell of a url.
Of course that's google's problem, not ours.

Here's a question for ya.
There's zillions of speed tests on the internet, but I'm trying to find a connectivity test that's not about speed, and I can't.
As in, I want it to see how long it takes to look up dns, I want to see how long it takes to connect, and the latency, things like that.
Once it gets going my mass data transfers are fast, but sometimes there's a lot of lag in starting a new connection or just hangups in the middle.

Are there any popular good diagnostic tests? I realize it would have to be a linux program not a webpage if it were going to be reall good, but I'll take anything at this point.

traceroute--or tracert on Windows--is a "low-level" network tool that will report round-trip times on a per-hop basis to a destination. It does its thing using ICMP packets, so it's best suited for gauging network delay. You'd need an application-specific tool to test how long it takes the destination to process a request.

For DNS, though, don't nslookup and dig have options to report the time it takes to fulfill a request?
tracebinder