ipv6-group's soup

“

We wish to inform you that as of Friday, 15 April 2011, the APNIC pool reached the Final /8 IPv4 address block, bringing us to Stage Three of IPv4 exhaustion in the Asia Pacific.

Last /8 address policy

IPv4 requests will now be assessed under section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region".

APNIC's objective during Stage Three is to provide IPv4 address space for new entrants to the market and for those deploying IPv6.

From now, all new and existing APNIC account holders will be entitled to receive a maximum allocation of a /22 from the Final /8 address space.

Act NOW on IPv6

We encourage Asia Pacific Internet community members to deploy IPv6 within their organizations. You can refer to APNIC for information regarding IPv6 deployment, statistics, training, and related regional policies.

Apply for IPv6 addresses now!

”

“

The global migration to IPv6 has been slow coming. Even as the last few remaining chunks of IPv4 address space are being allocated, many organizations around the world are just now beginning to look at IPv6. And what they're finding often isn't pretty: mediocre application support, security issues, and really long addresses that are hard to rattle off. It has been estimated that a significant move toward IPv6 won't be seen for at least five years, and IPv6 won't be on par with its predecessor for at least another ten.

This got some people within the IETF thinking about an alternative to the new protocol. Realizing that the primary goal of IPv6 was to provide an increased address space, they began to reconsider whether an entirely new protocol was really necessary in the first place. Still in its infancy, work is underway on a new IETF draft which ditches IPv6 altogether in favor of a simple extension to its predecessor: IPv4.1.

<!--break-->

The initiative is being spearheaded by Joe Kisanyu, who explains his team's motivation quite simply:

We've been going back and forth about how to implement IPv6 for years now, and frankly we just haven't been getting anywhere. So my team and I sat down and said, let's start from scratch and see if we can't do better this time around. After a few days, there was this epiphany: We can just add an octet to a regular IPv4 address!

This revelation quickly led to the development of IPv4.1, which is nearly identical in operation to IPv4 but features a slightly longer 40-bit address. The header specification below, adapted from RFC 791, should look familiar.

    0                   1                   2                   3                   4
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                Source Address                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Destination Address                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The solution here is pretty clever: an IPv4.1 has five octets instead of four, e.g. 28.112.45.108.89. Similarly, subnet masks can now range from zero for forty bits in length, e.g. 117.67.23.90.1/39 for a point-to-point link. And backward-compatibility is built in! Legacy IPv4 addresses will are expressed with the first octet set to zero, e.g. 0.192.168.0.1. DNS records for IPv4.1 addresses are to be designated as "B records" (successive to IPv4 A records).

The draft specification is still in a very rough form, but I was able to obtain an alpha copy of the IPv4.1 protocol stack implemented on Linux. Using the new address scheme comes quite naturally.

$ nslookup ipv41.testing.ietf.org
Server:     208.67.220.220
Address:    208.67.220.220#53

Non-authoritative answer:
Name:   ipv41.testing.ietf.org
Address: 1.64.170.98.32
$ ping 1.64.170.98.32
PING 1.64.170.98.32 (1.64.170.98.32) 56(84) bytes of data.
64 bytes from 1.64.170.98.32: icmp_seq=1 ttl=248 time=89.6 ms
64 bytes from 1.64.170.98.32: icmp_seq=2 ttl=248 time=90.0 ms
64 bytes from 1.64.170.98.32: icmp_seq=3 ttl=248 time=91.6 ms
^C
--- 1.64.170.98.32 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 89.672/90.479/91.668/0.925 ms

”

“

RFC 6177 has obsoleted its predecessor, updating or negating the three core recommendations as such:

1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices.

2) RFC 3177 specifically recommended using prefix lengths of /48, /64, and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that Classless Inter-Domain Routing (CIDR) continues to apply to all bits of the routing prefixes.

3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate.

In summary, the IETF has decided that deciding on prefix sizes for end sites is "an issue for the operational community." However, section five of the RFC does offer some guidance well wroth reading for those writing internal IPv6 address allocation policies.

”