gogoNET

IPv6 & Networking the Internet of Things

Although they may be temporary, it looks like large scale NATs will be
deployed as a bridge between v4 and v6 in ISP and mobile networks. What
are your thoughts, opinions and advice for operators contemplating
their deployment?

Views: 1248

Reply to This

Replies to This Discussion

In fact the carriers are deploying 4G on the same towers where 2G/3G emitters are mounted.

Most carriers don't wnat VoIP, they want to bill the phone calls (and the SMS via their 2G network which continues to have excellent coverage).

All the carriers I know even include a contractual clause that forbids users to use direct end-to-end communications (this include VoIP, P2P protocols, and instant messaging protocols that leave a session open for long; they admit HTTP via IPv6, relayed through their IPv4 tunnels, but they don't even offer a routable public IPv4 address on their mobile access networks).

So yes, they continue to allow only protocols that allows proxying or tunneling through their servers (and also allow them, or the NSA, to spy on these communications all over the world... think about the NSA scandals revealed by Snowden hero).

These practices are not only dangerous for privacy/confidentiality, they are also maintained by carriers as an anti-competitive counter mesure (against competing VoIP solutions where users could choose themselves their proxying/relaying service).

The promise of IPv6 is improved end-to-end security and privacy, elimination of routing bottlenecks, flexibility on network topology management, fast resolutoin of routing problems (when there's a broken route, because of a failing server): IPv6 routing ill work at the correct layer 3 (network) and should not depend on any upper layer using a static topology with single points of failures.

Finally, IPv6 will be highly needed now that, because of NSA spying, but also because of lots of malwares in the network, more and more sites will want to use secure direct communications, immune to intergerence by others. IPSEC is an absolute need.

And there won't be enough IPv4 addresses for everyone in the world with all his connected devices that are spreading (and it will be even worse when most communications will be mobile, leaving aside the "roaming' users that want to connect to their ISP and phone carrier using their own identity/account on their carrier, via another network). There won't even be enough port numbers on relyaing servers or NAT proxies/routers/firewalls.

Move the protocols down to the proper layer 3 for IP addressing where it should have remained. NAT is just an old hack mechanism which was intended to be used only locally (and first introduced in a time when users wanted to share locally their internet connection in their home with very few other hosts). NAT has never been designed to scale over the full network of a carrier, where it is really a much more severe (and dangerous) hack.

Also let's not forget one essential thing:

It's not uncommon today that a single host needs to have dozens of sessions open with remotes on the Internet. The ongoing development of our OSes and the multiplication of connected applications (even on mobiles) means that soon we would also suffer (if we only have a single IP address available on the host) of port number exhaustion.

In addition some port ranges are restricted by security profiles on the host for specific protocols. This limits the number of usable ports.

With IPv6, the same host can have MANY IPv6 adresses available that they can listen and from which they can establish communications via the same IPv6 carrier. Each subscrber of the ISP should be offered a 48-bit wide range of IPv6 addresses that are then allocated freely on the private network, and mappable to private IPv4 or IPv6 addresses, or subdivided into subnetworks, or mapped automatically by using the 48-bit space to map the 48-bit MAC addresses with ZERO CONFIGURATION.

This means: no more need of DHCP on the internet access router to manage individual hosts on the private LAN, devices on the private LAN can try using directly an IPv6 address within the 48-bit block whose prefix is advertized on the LAN (with DHCP by the access router that also needs ZERO configuration):

The DHCP router can advertize directly the 80-bit prefix of the IPv6 address block that was allocated to the ISP subscriber as being available for routing, and it does not need to translate these addresses.

It just needs to firewall the IPv6 address spaces used on the LAN, and here again this requires ZERO configuration if the private LAN allocates its own private IPv6 addresses in the standard spaces made for this use.

The DHCP server will then advertize these address spaces:

- the local private IPv6 address space used on the LAN. DHCP will be useful here as this allows the local network administrator to manage the list of authorized hosts, and manage an internal private routing or local subnetworks: a 48-to-64 bit IPv6 space for each host (48-bit will be used if the private LAN needs subnetworks).

- the local IPv4 address used on a host (a single one per host)

- the 48-bit address space usable by the host for EACH internet carrier.

- the DHDP server on the LAN may also advertize for each address or address range some identification info about which kind of network it is (for example a user readable name of the network such as "Internet via Verizon", or "Sales department, Private Gizmo Company corporate network") and a challenge key that may be requested by this network in order to connect to it.

Then every local host has now solved the problem of port exhaustion: you can run for example multiple web servers on your host on their regular port 80, by the host itself:

- the webserver application will query the OS to get a new IPv6 address within the same 48-bit block

- the OS on the local host manages this 48-bit block locally without having to synchronize with the routers.

- it becomes possible for the local application (such as a local webserver) to select which carrier or local network to listen incoming connection.

- it becomes possible with the same mechanism to allow incoming connections from specific local subnetworks (the local OS must be configured to manage these subblocks, and enumerate them, for example by using a local DNS server)

- NO application ever needs to modify its protocol: it just has to use a single 128-bit long IPv6 address instead for each listening port, instead of a single 32-bit long IPv4 address; optionally the same application can listen multiple ports, one for each Internet carrier network or local network or subnetwork.

- Locally, the configuration of firewalls is highly simplified: no more need of UPnP for example, except to discover local devices or services (including multimedia devices, such as smart TV's or set-top boxes, or connected small appliances).

- Multiple Internet carriers in parallel may be configured for the local network, it is possible to offer the choice, or for the local admin to configure preferences (for example based on usave/volume cost, or on reliability, or QoS parameters such as real-ime) between these carriers. This is great to offer a continued Internet experience when one of the carrier fails on its own connection or when it is no longer available (for example when a 4G mobile user is no longer outdoor, and enters a place where the carrier is no longer accessible, or when he comes back at home and wants to use the faster fixed broadband connection, or when he leaves home and wants to use the 4G network again, or when he comes at work and want to use the carrier configured in the local place where hos device has been preauthorized: no more need to change local configuration of the device that can keep track of these multiple authorizations).

All this won't be possible with IPv4.

Additional notes:

* The DHCP server runs on the local network, and is not necessarily on the same locally accessible device than internet routers. It can be configured separately.

* Local applications running on a host can listen to multiple ports from different cariers, and can also automatically get their list from the OS: gethostaddress() can return the list of addresses instead of a single one, and you can specify an address type if needed, but modern applications should not need this if each address has some identificcation information available from the OS by using some DHCP query service, or by using UPnP if needed.

* Local applications (e.g. a local webserver or file/media sharing or streaming protocol) can present different contents for distinct carriers: specific preselected known carriers would get more direct access to the service, others would be allowed but will need to connect to a local account, using a connection screen

* If the application does not accept remote connections, it can just listen only the specific list of networks/subnetworks allowed to connect and reject other incoming connections during the accept() - This is exactly the same thing with existing IPv4-only applications where you preconfigure some authorized address blocks for remotes with IPv4, the only difference being the length of addresses, and the fact that IPv6 prefers using simpler CIDR address prefixes, instead of address ranges (now customarily used in IPv4), but a prefix length combined with the address block gives a funtionally equivalent range with a starting address and an ending address.

Typically the only needed change in the application is that it should not use a storage structure (for each range stored in an array or vector) like:

    class addr_range {

       int32 start, end; // IPv4-only

    }:

    // alternative

    class addr_CIDR_range {

       int32 addr, mask; // IPv4-only

    }:

but something like:

    struct addr_range {

       addr_t start, end; // where addr_t is an array of at least 8 bytes, or the generic structure returned by gethostaddr()

    };

    // alternative

    struct addr_range {

       int prefix_length;

       addr_t start;

    };

And the fact that IPv6 are not comparable directly like 32-bit or 64-bit integers (you need to compare byte arrays).

These structures may also contain an additional integer for QoS type, if the application needs it (it will be ignored in IPv4), or other info and flags (independant of the address format) about each range (everything that is already used in the initial IPv4-only structure.

But the socket API (or Winsock) on most OSes already provides such as structure used in listen() and accept(). adapting to IPv6 is not complicate, changes are minimal for applications or even in firewalls.

When using modern oblject languages (or functional languages), this can be modeled in a more complete class hiding the details of these formats, and providing a toString() method for getters of the start/end properties, and a single constructor from a string in either IPv4 or IPv6 format.

RSS

Training

IoT & IPv6 Networking Conference

Product Information

Fill out my online form.

© 2014   Created by gogo6.

Badges  |  Report an Issue  |  Terms of Service