ISOC Logo

IPv6 in the Home Makes Sense

MEMBER BRIEFING 7 < Main Index

May 2002 By A. Williams, B. Haberman, R. Kermode

1. Background

Home networks today are predominantly comprised of PCs running IPv4, perhaps behind a home gateway. There is, however, a trend away from the PC-only household towards a much richer set of devices and applications involving entertainment media, conferencing, and command & control that will see the rise of significantly more complex home networking scenarios. This paper aims to show that IPv6 will make such home networks possible and that IPv6-only home networks can be built today which support everything today's home gateways provide. Further, this paper will show that IPv6 in the home allows applications to be easily deployed that have proved difficult for IPv4 home gateways.

2. Technical Issues

2.1 The needs of home networking

  • Simple Configuration

    The home is unlike environments where IP is typically deployed today in one key way: the homeowner is not a trained network administrator. Therefore home-based IP must be deployable by average consumers, people who generally know nothing of the mechanics of IP, routing, DNS, etc.

  • Simple Application Development

    In a good home network architecture, it is easy to
    develop applications that communicate between devices inside the home and further afield to services on the Internet. IPv4 has historically been an excellent choice but is reaching its limits as the Internet continues to grow explosively. Technologies like Network Address Translation (NAT) are prolonging the useful life of the IPv4 Internet but introduce additional complexity for
    peer-to-peer style applications.

  • Security

    Securing home networks is as important as putting locks on a home's windows and doors. Home networks connected to the Internet need simple and consistent security mechanisms. The increasing use of wireless networks further complicates the security issue, by enabling access to the home network without having to be physically connected.

    The most important feature of a security scheme is probably that it is ubiquitously available. If this is not the case, application developers will be forced to implement their own solutions, thereby resulting in a plethora of incompatible solutions that will mostly likely be hard to configure consistently.

2.2 What IPv6 Offers

IPv6 offers a significantly improved starting point for general purpose home-networking than IPv4. The main benefits afforded by IPv6 can be summarized as follows:

  • Large address space: more than enough address space to allow assignment of globally unique IPv6 addresses to every device in the home.
  • Auto-configuration: hosts can automatically construct link-local addresses on their own and acquire additional network prefixes from routers as needed.
  • Automatic tunneling techniques: allowing IPv6 to be deployed even when the local provider doesn't support it.
  • Mandated security: the IP Security protocols (IPSec) are mandatory in IPv6 stacks, so application designers can rely on their presence.
  • A future path: applications using IPv6 can avoid completely the problems associated with the use of private IPv4 addressing and NATs [NAT-COMP].

2.3 Building a Pure IPv6 Home Network Today

A functional IPv6-only home network can be constructed using just one global IPv4 address, and the following three services:

  1. A 6to4 router [6to4] providing IPv6 address space to the home, and transporting IPv6 datagrams over the IPv4 Internet
  2. A DNS proxy [DNS-ALG] running on a dual stack gateway so that IPv4 address records can be translated into IPv6 address records usable by IPv6-only clients.
  3. A protocol translating NAT [NAT-PT], or application proxy to support connectivity between the IPv6-only devices in the home network, and the existing IPv4 Internet

The DNS proxy and NAT-PT (or proxy) interoperate as illustrated in the following diagram:

Diagram

Diagram shows 3 primary entities

IPv4 http connection, with arrow going to IPv6 only home network, showing mapping between IPv6 connection and IPv4 mapped addresses routed to the NAT-PT.
On the other side of the diagram, it shows the relationship of the DNS proxy server to the IPv6 home connection.
step 1: DNS request is made.
step 2: DNS request is sent to DNS proxy.
steps 3 adn 45: DNS proxy sends response back with IP address mapped.
this completes the mapping of IPv4 to IPv6.

The availability of IPv6 through the use of 6to4 allows applications to be easily deployed that have proved problematic in IPv4 networks using NATs. Three examples are: home-to-home videoconferencing, control of a device from outside the home (e.g. a VCR), and access to information (e.g. a camera) inside the house.

2.4 Missing pieces

Work on IPv6 has been progressing for many years, but as yet widespread adoption has not occurred. Support for IPv6 in popular operating systems and applications are only now becoming widely available. Key IPv6 specifications are now sufficiently mature that combinations of technologies can be shown to provide workable and useful solutions - for example, home networking.

Standards are under active development in the following areas: name service in the home using stateless DNS server discovery or multicast DNS, and transporting IPv6 through IPv4 NATs.
Simple management of a DNS namespace in the home needs more attention and is relevant to both IPv4 and IPv6 home networks.

3. Implications

Sufficient standards exist to show that IPv6 can benefit home networks. Vendors of home networking hardware should look to incorporate IPv6 functionality into their products in the near term. IPv6 support may be integrated into the customer's equipment, or in the network infrastructure.

With increasing support for IPv6 in popular operating systems, developers can expect IPv6 to remove application complexities introduced by IPv4 NATs.

4. ISOC Position

Successful introduction of IPv6 at the edge of the network and later in the core of the network, is one of the most strategic requirements for the continued growth of the Internet. ISOC will continue to support relevant standards work, will support related education and training activities, and will be watchful for any public policy issues affecting the deployment of IPv6.

This article is also available in PDF and ASCII

References

A longer version of this paper can be found at:
www.ipv6forum.org/

6to4 B. Carpenter and K. Moore
Connection of IPv6 Domains via IPv4 Clouds
RFC 3056, February 2001.

DNS-ALG P. Srisuresh et al
DNS extensions to Network Address Translators (DNS_ALG)
RFC 2694, September 1999.

NAT P. Srisuresh and M. Holdrege
IP Network Address Translator (NAT) Terminology and Considerations
RFC 2663, August 1999.

NAT-COMP M. Holdrege et al
Protocol Complications with the IP Network Address Translator"
RFC 3027, January 2001.

NAT-PT G. Tsirtsis and P. Srisuresh
Network Address Translation - Protocol Translation (NAT-PT)
RFC 2766, February 2000.

About the Authors

Aidan Williams is a senior research engineer in Motorola's Australian Research Centre. His interests include zero-configuration networks, home networking, security, filesystems, and operating systems. He has extensive experience in network and system administration.

Brian Haberman is an independent researcher concentrating on IPv6, multicast, and inter-domain routing. He is an active contributor to the IETF and is a member of the IPv6 Forum Technical Directorate.

Roger Kermode is a Principal Research Engineer in and Manager of the Sydney Networks Research Lab in Motorola's Australian Research Centre. He co-chairs the IETF Reliable Multicast Transport Working Group and has varied research interests in multicast, zero-configuration, and ad-hoc networking.

Acknowledgments

This paper produced with editorial support from the IPv6 Forum.

Acknowledgments

The ISOC Member Briefing series is made possible through the generous assistance of ISOC's Platinum Program Sponsors: Afilias, APNIC, ARIN, Microsoft, and the RIPE NCC, Sida. More information on the Platinum Sponsorship Program...

About the Background Paper Series

Published by:
The Internet Society
1775 Wiehle Avenue, Suite 102
Reston, Virginia 20190 USA
Tel: +1 703 326 9880
Fax: +1 703 326 9881

4, rue des Falaises
CH-1205 Geneva
Switzerland
Tel: +41 22 807 1444
Fax: +41 22 807 1445

Email: info@isoc.org
Web: www.isoc.org

Series Editor: Martin Kupres

Copyright C Internet Society 2005.
All rights reserved.