ISP. This can be done through explicit prefix delegation (e.g.,
[DHCPV6, PREFIXDHCPV6]), or if the ISP is advertising a /64 prefix on
the link, such a link can be extended by the use of an ND proxy or a
bridge.
An ND proxy can also be used to extend a /64 prefix to multiple
physical links of different properties (e.g., an Ethernet and a PPP
link).
4.1.1. Extending a Subnet to Span Multiple Links
A /64 subnet can be extended to span multiple physical links using a
bridge or ND proxy. Bridges can be used when bridging multiple
similar media (mainly, Ethernet segments). On the other hand, an ND
proxy must be used if a /64 prefix has to be shared across media
(e.g., an upstream PPP link and a downstream Ethernet), or if an
interface cannot be put into promiscuous mode (e.g., an upstream
wireless link).
Extending a single subnet to span from the ISP to all of the
unmanaged network is not recommended, and prefix delegation should be
used when available. However, sometimes it is unavoidable. In
addition, sometimes it’s necessary to extend a subnet in the
unmanaged network, at the "customer-side" of the gateway, and
changing the topology using routing might require too much expertise.
The ND proxy method results in the sharing of the same prefix over
several links, a procedure generally known as "multi-link subnet".
This sharing has effects on neighbor discovery protocols, and
possibly also on other protocols such as LLMNR [LLMNR] that rely on
"link local multicast". These effects need to be carefully studied.
4.1.2. Explicit Prefix Delegation
Several networks have already started using an explicit prefix
delegation mechanism using DHCPv6. In this mechanism, the gateway
uses a DHCP request to obtain an adequate prefix from a DHCP server
managed by the Internet Service Provider. The DHCP request is
expected to carry proper identification of the gateway, which enables
the ISP to implement prefix delegation policies. It is expected that
the ISP assigns a /48 to the customer. The gateway should
automatically assign /64s out of this /48 to its internal links.
DHCP is insecure unless authentication is used. This may be a
particular problem if the link between gateway and ISP is shared by
multiple subscribers. DHCP specification includes authentication
options, but the operational procedures for managing the keys and
methods for sharing the required information between the customer and
the ISP are unclear. To be secure in such an environment in
practice, the practical details of managing the DHCP authentication
need to be analyzed.
4.1.3. Recommendation
The ND proxy and DHCP methods appear to have complementary domains of
application. ND proxy is a simple method that corresponds well to
the "informal sharing" of a link, while explicit delegation provides
strong administrative control. Both methods require development:
specify the interaction with neighbor discovery for ND proxy; provide
security guidelines for explicit delegation.
4.2. Communication Between IPv4-only and IPv6-capable Nodes
During the transition phase from IPv4 to IPv6, there will be IPv4-
only, dual-stack, and IPv6-only nodes. In theory, there may be a
need to provide some interconnection services so that IPv4-only and
IPv6-only hosts can communicate. However, it is hard to develop a
translation service that does not have unwanted side effects on the
efficiency or the security of communications. As a consequence, the
authors recommend that, if a device requires communication with
IPv4-only hosts, this device implements an IPv4 stack. The only
devices that should have IPv6-only connectivity are those that are
intended to only communicate with IPv6 hosts.
4.3. Resolution of Names to IPv6 Addresses
There are three types of name resolution services that should be
provided in case B: local IPv6 capable hosts must be able to obtain
the IPv6 addresses of correspondent hosts on the Internet, they
should be able to publish their address if they want to be accessed
from the Internet, and they should be able to obtain the IPv6 address
of other local IPv6 hosts. These three problems are described in the
next sections. Operational considerations and issues with IPv6 DNS
are analyzed in [DNSOPV6].
4.3.1. Provisioning the Address of a DNS Resolver
In an unmanaged environment, IPv4 hosts usually obtain the address of
the local DNS resolver through DHCPv4; the DHCPv4 service is
generally provided by the gateway. The gateway will also use DHCPv4
to obtain the address of a suitable resolver from the local Internet
service provider.
The DHCPv4 solution will suffice in practice for the gateway and also
for the dual-stack hosts. There is evidence that DNS servers
accessed over IPv4 can serve arbitrary DNS records, including AAAA
records.
Just using DHCPv4 will not be an adequate solution for IPv6-only
local hosts. The DHCP working group has defined how to use
(stateless) DHCPv6 to obtain the address of the DNS server
[DNSDHCPV6]. DHCPv6 and several other possibilities are being looked
at in the DNSOP Working Group.
4.3.2. Publishing IPv6 Addresses to the Internet
IPv6 capable hosts may be willing to provide services accessible from
the global Internet. They will thus need to publish their address in
a server that is publicly available. IPv4 hosts in unmanaged
networks have a similar problem today, which they solve using one of
three possible solutions:
* Manual configuration of a stable address in a DNS server;
* Dynamic configuration using the standard dynamic DNS protocol;
* Dynamic configuration using an ad hoc protocol.
Manual configuration of stable addresses is not satisfactory in an
unmanaged IPv6 network: the prefix allocated to the gateway may or
may not be stable, and in any case, copying long hexadecimal strings
through a manual procedure is error prone.
Dynamic configuration using the same type of ad hoc protocols that
are common today is indeed possible, but the IETF should encourage
the use of standard solutions based on Dynamic DNS (DDNS).
4.3.3. Resolving the IPv6 Addresses of Local Hosts
There are two possible ways of resolving the IPv6 addresses of local
hosts: one may either publish the IPv6 addresses in a DNS server for
the local domain, or one may use a peer-to-peer address resolution
protocol such as LLMNR.
When a DNS server is used, this server could in theory be located
anywhere on the Internet. There is however a very strong argument
for using a local server, which will remain reachable even if the
network connectivity is down.
The use of a local server requires that IPv6 capable hosts discover
this server, as explained in 4.3.1, and then that they use a protocol
such as DDNS to publish their IPv6 addresses to this server. In
practice, the DNS address discovered in 4.3.1 will often be the
address of the gateway itself, and the local server will thus be the
gateway.
An alternative to using a local server is LLMNR, which uses a
multicast mechanism to resolve DNS requests. LLMNR does not require
any service from the gateway, and also does not require that hosts
use DDNS. An important problem is that some networks only have
limited support for multicast transmission, for example, multicast
transmission on 802.11 network is error prone. However, unmanaged
networks also use multicast for neighbor discovery [NEIGHBOR]; the
requirements of ND and LLMNR are similar; if a link technology
supports use of ND, it can also enable use of LLMNR.
4.3.4. Recommendations for Name Resolution
The IETF should quickly provide a recommended procedure for
provisioning the DNS resolver in IPv6-only hosts.
The most plausible candidate for local name resolution appears to be
LLMNR; the IETF should quickly proceed to the standardization of that
protocol.
4.4. Security Considerations in Case B
The case B solutions provide global IPv6 connectivity to the local
hosts. Removing the limit to connectivity imposed by NAT is both a
feature and a risk. Implementations should carefully limit global
IPv6 connectivity to only those applications that are specifically
designed to operate on the global Internet. Local applications, for
example, could be restricted to only use link-local addresses, or
addresses whose most significant bits match the prefix of the local
subnet, e.g., a prefix advertised as "on link" in a local router
advertisement. There is a debate as to whether such restrictions
should be "per-site" or "per-link", but this is not a serious issue
when an unmanaged network is composed of a single link.
5. Meeting Case C Requirements
Case C is very similar to case B, the difference being that the ISP
is not dual-stack. The gateway must thus use some form of tunneling
mechanism to obtain IPv6 connectivity, and an address prefix.
A simplified form of case B is a single host with a global IPv4
address, i.e., with a direct connection to the IPv4 Internet. This
host will be able to use the same tunneling mechanisms as a gateway.
5.1. Connectivity
Connectivity in case C requires some form of tunneling of IPv6 over
IPv4. The various tunneling solutions are discussed in section 2.
The requirements of case C can be solved by an automatic tunneling
mechanism such as 6to4 [6TO4]. An alternative may be the use of a
configured tunnels mechanism [TUNNELS], but as the local ISP is not
IPv6-enabled, this may not be feasible. The practical conclusion of
our analysis is that "upgraded gateways" will probably support the
6to4 technology, and will have an optional configuration option for
"configured tunnels".
The tunnel broker technology should be augmented to include support
for some form of automatic configuration.
Due to concerns with potential overload of public 6to4 relays, the
6to4 implementations should include a configuration option that
allows the user to take advantage of specific relays.
6. Meeting the Case D Requirements
In case D, the ISP only provides IPv6 services.
6.1. IPv6 Addressing Requirements
We expect IPv6 addressing in case D to proceed similarly to case B,
i.e., use either an ND proxy or explicit prefix delegation through
DHCPv6 to provision an IPv6 prefix on the gateway.
6.2. IPv4 Connectivity Requirements
Local IPv4 capable hosts may still want to access IPv4-only services.
The proper way to do this for dual-stack nodes in the unmanaged
network is to develop a form of "IPv4 over IPv6" tunneling. There
are no standardized solutions and the IETF has devoted very little
effort to this issue, although there is ongoing work with [DSTM] and
[TSP]. A solution needs to be standardized. The standardization
will have to cover configuration issues, i.e., how to provision the
IPv4 capable hosts with the address of the local IPv4 tunnel servers.
6.3. Naming Requirements
Naming requirements are similar to case B, with one difference: the
gateway cannot expect to use DHCPv4 to obtain the address of the DNS
resolver recommended by the ISP.
7. Recommendations
After a careful analysis of the possible solutions, we can list a set
of recommendations for the V6OPS working group:
1. To meet case A and case C requirements, we need to develop, or
continue to develop, four types of tunneling technologies:
automatic tunnels without NAT traversal such as [6TO4],
automatic tunnels with NAT traversal such as [TEREDO],
configured tunnels without NAT traversal such as [TUNNELS,
TSP], and configured tunnels with NAT traversal.
2. To facilitate the use of configured tunnels, we need a
standardized way for hosts or gateways to discover the tunnel
server or tunnel broker that may have been configured by the
local ISP.
3. To meet case B "informal prefix sharing" requirements, we would
need a standardized way to perform "ND proxy", possibly as part
of a "multi-link subnet" specification. (The explicit prefix
delegation can be accomplished through [PREFIXDHCPV6].)
4. To meet case B naming requirements, we need to proceed with the
standardization of LLMNR. (The provisioning of DNS parameters
can be accomplished through [DNSDHCPV6].)
5. To meet case D IPv4 connectivity requirement, we need to
standardize an IPv4 over IPv6 tunneling mechanism, as well as
the associated configuration services.
8. Security Considerations
This memo describes the general requirements for transition
mechanisms. Specific security issues should be studied and addressed
during the development of the specific mechanisms.
When hosts which have been behind a NAT are exposed to IPv6, the
security assumptions may change radically. This is mentioned in
sections 3.2 and 4.4. One way to cope with that is to have a default
firewall with a NAT-like access configuration; however, any such
firewall configuration should allow for easy authorization of those
applications that actually need global connectivity. One might also
restrict applications which can benefit from global IPv6 connectivity
on the nodes.
Security policies should be consistent between IPv4 and IPv6. A
policy which prevents use of v6 while allowing v4 will discourage
migration to v6 without significantly improving security. Developers
and administrators should make sure that global Internet connectivity
through either IPv4 or IPv6 is restricted to only those applications
that are expressly designed for global Internet connectivity.
Several transition technologies require relays. There are concerns
that improperly designed protocols or improperly managed relays could
open new avenues for attacks against Internet services. This issue
should be addressed and mitigated in the design of the transition
technologies and in the deployment guides for relays.
9. Acknowledgements
This memo has benefited from the comments of Margaret Wasserman,
Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms,
Bill Sommerfeld, and Fred Templin. Tim Chown provided a lot of the
analysis for the tunneling requirements work.
10. References
10.1. Normative References
[UNMANREQ] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Unmanaged Networks IPv6 Transition Scenarios",
RFC 3750, April 2004.
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[NEIGHBOR] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[6TO4] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[6TO4ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay
Routers", RFC 3068, June 2001.
[TUNNELS] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[DNSDHCPV6] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[PREFIXDHCPV6] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
RFC 3633, December 2003.
10.2. Informative References
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R.
Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", RFC 3489, March 2003.
[DNSOPV6] Durand, A., Ihren, J., and P. Savola. "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress.
[LLMNR] Esibov, L., Aboba, B., and D. Thaler, "Linklocal
Multicast Name Resolution (LLMNR)", Work in Progress.
[TSP] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel
Setup Protocol(TSP)", Work in Progress.
[DSTM] Bound, J., "Dual Stack Transition Mechanism", Work in
Progress.
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", Work in Progress.
11. Authors’ Addresses
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Suresh Satapati
Cisco Systems, Inc.
San Jose, CA 95134
USA
EMail: satapati@cisco.com
Ronald van der Pol
NLnet Labs
Kruislaan 419
1098 VA Amsterdam
NL
EMail: Ronald.vanderPol@nlnetlabs.nl
12. Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.