Case Studies of Recent IP Problems in Homes

2.1 IPv4 global addresses

On February 3, 2011, the Internet Assigned Numbers Authority (IANA), the organization that manages the allocation of IPv4 global addresses used mainly for establishing Internet connections, announced that these addresses had been exhausted. Then, about two months later on April 15, the Japan Network Information Center (JPNIC), the organization in charge of allocating and registering IP addresses in Japan, also announced the exhaustion of IPv4 addresses. At present, this applies only to IPv4 global addresses allocated to Internet service providers (ISPs) and corporations; the efficient use of existing addresses means that Internet usage is continuing as usual. However, as new allocation of IPv4 global addresses is no longer possible, it may not be possible to launch new services using the Internet via IPv4 connections.

2.2 Case study: slow Internet access

The following describes a problem related to the allocation and exhaustion of IPv4 global addresses. Specifically, a customer using the FLET’S service reported that Internet access was sometimes slow.

2.2.1 Customer’s equipment configuration and conditions at time of problem occurrence

The equipment and systems used to establish this customer’s Internet connection are shown in Fig. 1. In this setup, a Point-to-Point Protocol over Ethernet (PPPoE) session is established at the broadband router, while the customer equipment is connected on the local area network (LAN) side. After connecting to the Internet from a home personal computer (PC), the customer sometimes found that the connection was slow. A check of the broadband router log around the times the problem occurred revealed that PPPoE sessions had been released ten or more times in one day, as shown in Fig. 2.

Fig. 1. Customer’s Internet connection configuration.

Fig. 2. Excerpt of PPPoE session release log in broadband router.

2.2.2 Inspection method and analysis results

We performed packet capture on the wide area network (WAN) side of the broadband router at the times the problem was occurring and then analyzed in detail all of the captured data corresponding to the time of that PPPoE session release indicated in the broadband router log. By doing this, we were able to determine why the problem was occurring.

(1) Log analysis at PPPoE session release time

We analyzed captured data before and after a PPPoE session release time as recorded on the broadband router log (Fig. 2). As shown in Fig. 3, the broadband router first receives and acknowledges a PPP Termination Request from the network side and then receives and acknowledges a PPPoE Active Discovery Terminate (PADT) signal, also from the network side. These actions result in the release of the PPPoE session.

Fig. 3. Session release sequence.

(2) Captured data before/after PPPoE session release

Captured data before and after a PPPoE session release (marked by * in the broadband router log of Fig. 2) are outlined on the log and shown in Fig. 4. The data indicate that the 10-minute period prior to the PPP Termination Request from the network was an idle state between the broadband router and ISP (in this case, an idle Internet connection). The same was true for PPPoE session releases in other time slots; all were preceded by a 10-minute idle state. As shown in the figure, about 6 seconds was needed to reestablish a PPPoE session after its release, so it can be assumed that the system response would seem slow to the user if an Internet connection were to be attempted during such a session-reestablishment period.

Fig. 4. Captured data before and after session release.

2.2.3 Discussion based on analysis results

The analysis results (1) and (2) above indicated that communications control on the ISP side would release a PPPoE connection (perform disconnection processing) if an idle state existed for at least 10 minutes. The ISP most likely does this for allocated addresses that are not being actively used, with the intention being to achieve more effective use of IPv4 global addresses.

2.2.4 Cause of problem

The results of analysis suggested that this problem was caused by communications-control measures on the ISP side and not by any problems in the FLET’S network. We therefore contacted the ISP manager in question and confirmed that processing to release a PPPoE connection would indeed be initiated on the ISP side to recover IPv4 global addresses if an idle state continued for at least 10 minutes.

Looking forward, we can envision a large-scale rollout of the IPv6 next-generation Internet protocol in response to this problem, and we can also consider the introduction of a mechanism to achieve more efficient use of IPv4 global addresses.

3.1 IPv6 features

IPv6 was developed as the next-generation IP to succeed IPv4, which has been the protocol used to support Internet connections to date. As the scale of the Internet grew over the years, a number of shortcomings in IPv4 came to light, the most obvious of which is the exhaustion of IPv4 global addresses. Another problem is network address translation (NAT) traversal.

The aim of NAT traversal is to use IPv4 global addresses efficiently (economically) on the WAN side. With this method, a broadband router can increase the number of connected terminals by using private addresses on the LAN side and converting addresses by NAT (more accurately, network address and port translation (NAPT) since the process includes port translation). This method, however, prevents a terminal on the LAN side from being directly specified from the outside, thereby hampering bidirectional communications. Specifically, it can result in complicated settings and problematic communications in such applications as 050-type IP telephony and online multiplayer games.

In contrast to the above, IPv6 extends the address space to 128 bits, thereby resolving the problem of an insufficient number of global IP addresses. The features of IPv4 and IPv6 are listed in Table 1. IPv4 uses 32-bit addresses, which means that it can handle 2³² or about 4.3 billion IP addresses. However, with 128-bit addresses, IPv6 can handle 2¹²⁸ or about 3.4 × 10³⁸ IP addresses, a significantly larger number. If all of these IP addresses were to be allocated to the entire human race (which we set to 7 billion people for calculation purposes), the number of addresses per person would turn out to be 480 × 10²⁶. It can therefore be said that the number of IPv6 addresses that can be implemented is essentially infinite. The IPv6 specifications also feature enhanced security functions and the addition of Internet Protocol Security (IPsec) as a standard function enabling the creation of a secure communications environment.

Table 1. IPv4 and IPv6 features.

3.2 IPv6 address notation

The IPv6 address notation method is shown in Fig. 5. Since the address space has been extended to 128 bits in IPv6, a hexadecimal (0–f) notation method has been adopted that divides the 128 bits (16 bits × 8) into 8 groups of 16 bits connected by colons.

Fig. 5. IPv6 address notation.

Furthermore, as shown in Fig. 6, the IPv6 unicast address used for Internet connections treats the first 64 bits of the 128-bit address as a subnet prefix and the last 64 bits as an interface identifier making for a clearly defined address format. In IPv4 addresses, the bit sequences for the network address and host address could change, which means that address processing at network interfaces has been mainly handled by software. In short, while achieving high-speed processing was problematic with IPv4 addresses, this uniform method of using bit sequences in IPv6 addresses means that high-speed processing can be achieved by hardware.

Fig. 6. IPv6 unicast address structure.

3.3 IPv6 address allocation method

Unlike IPv4, the address allocation method specified by IPv6 automatically allocates IP addresses for establishing IPv6 connections. This IPv6 automatic address generation scheme, called IPv6 plug and play, is shown in Fig. 7. The convenience of IPv6 plug and play is analogous to the ease of using a home appliance by simply plugging it into a power outlet on a wall. When a LAN cable is connected to an IPv6-compatible terminal (and authentication is performed in the case of a wireless LAN) (1), the terminal transmits a Router Solicitation (RS) message (2), and an IPv6 router in the network returns a Router Advertisement (RA) message (3). The IPv6-compatible terminal then extracts from this RA message the information needed to automatically generate an IPv6 unicast address (4). The above process can be mainly accomplished by hardware, which means that an IPv6 unicast address can be configured in even less time that it takes to boot up the OS (operating system) on a PC running Windows.

Fig. 7. IPv6 automatic address generation method.

3.4 Toward full-scale deployment of IPv6

The World IPv6 Launch was held on June 6, 2012 as a global event to introduce the new protocol. The intention behind this event was to convey the idea that IPv6 would be supported on an ongoing basis well beyond the launch date. This includes support for IPv6 standards by IP-network-compatible terminals to be marketed in the future as well as IPv6 support for website connections. The holding of this event signified a transition to a full-scale IPv6 deployment stage.

3.5 Case study: Security Tools cannot be downloaded on FLET’S HIKARI NEXT

We present here a case study of a problem related to IPv6 connections. Specifically, a customer subscribing to the FLET’S HIKARI NEXT High-speed Type broadband access service was unable to download Security Tools (the name of this service at NTT WEST, but called FLET’S VIRUS CLEAR v6 at NTT EAST) from FLET’S simple setup tools. Additionally, while IPv4 Internet communications presented no problems, connections to IPv6 sites such as an IPv6 service information site could not be achieved.

3.5.1 Customer’s equipment configuration and conditions at time of problem occurrence

The customer’s Internet connection configuration is shown in Fig. 8. Here, one PC running Windows 7 was connected to the ONU, and Internet connections to the PC were established using installed startup tools (i.e., PPPoE connection functions in the OS). In this environment, IPv4 Internet communications were able to be performed without incident, but Security Tools could not be downloaded from the FLET’S simple setup tools.

Fig. 8. Customer’s Internet connection configuration.

3.5.2 Inspection method and analysis results

We performed packet capture between the ONU and PC at the time the problem occurred. We also performed packet capture when connecting a test PC that was shown to be capable of downloading Security Tools, and we compared and analyzed the captured data between these two PCs.

(1) Problem trigger

The sequence flow at the time of a Security Tools download-destination connection failure is shown in Fig. 9. To begin with, the series of operations from turning on the PC to determining the IPv6 unicast address for connecting to the FLET’S HIKARI NEXT service (NGN: Next-Generation Network), was executed normally. This was followed by name resolution (DNS: Domain Name Service) of the URL (uniform resource locator) for the Security Tools download destination, which was likewise performed without any problems.

Fig. 9. Sequence at time of Security Tools download-destination connection failure.

Next, the PC transmitted a hypertext transfer protocol (HTTP) synchronize (SYN) request to initiate the HTTP connection process. Immediately after this, the NTT network router transmitted a Neighbor Solicitation (NS) message (media access control (MAC) address request in IPv6 communications) to the PC’s NGN unicast address. However, no Neighbor Advertisement (NA) message (MAC address reply in IPv6 communications) was subsequently transmitted from the PC side, so the NTT network router entered a state in which it could not move to the next sequence. Finally, after the PC repeated the transmission of the HTTP SYN request three to four times, the connection terminated. At this time, the message “Cannot Display” appeared on the PC browser’s screen. The above analysis led us to conclude that there was some reason why NA messages were not being transmitted from the PC side.

(2) PC operation at time of problem occurrence

In searching for the reason why no NA messages were being transmitted from the PC, we found that NA transmission for that NGN unicast address was being blocked by the PC’s Windows firewall.

3.5.3 Discussion based on analysis results

We also found that default settings for the Windows firewall do not block NA transmissions. However, depending on the security software preinstalled in PCs, settings that restrict IPv6 communications can also be made, and we surmise that those default settings were changed at the time of product shipment.

3.5.4 Cause of problem

The search for the reason why no NA messages were being issued by the customer’s PC revealed that NA transmissions for that NGN unicast address were being blocked due to that PC’s Windows firewall settings. This is why the PC entered into a state in which it could not connect with an IPv6 site. Consequently, changing the Windows firewall settings or temporarily disabling the firewall made it possible to connect to the Security Tools download site and download those tools. This case study underscores the importance of checking PC settings in the event that specific types of communications cannot be performed.