Sections

About 6NET Partners Publications Calendar Events Related Sites
Private Area

Standards Contributions

Request for Comments (RFCs)

• RFC 4242: Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.
  Published: November 2005
• RFC 4057: IPv6 Enterprise Network Scenarios
  This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios. Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment. The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document.
  Published: June 2005
• RFC 4076: Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
  IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.
  Published: May 2005
• RFC 4038: Application Aspects of IPv6 Transition
  As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to develop IP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period.
  Published: March 2005
• RFC 3964: Security Considerations for 6to4
  The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems.
  Published: December 2004
• RFC 3956: Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
  This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306.
  Published: November 2004
• RFC 3627: Use of /127 Prefix Length Between Routers Considered Harmful
  In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This document discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.
  Published: September 2003

Internet Drafts (I-Ds)

• I-D: IPv6 Multicast Deployment Issues  (Expired)
  This memo describes known issues with IPv6 multicast, and provides historical reference of how some earlier problems have been resolved.
  Published: February 2005   Version: 2
• I-D: Route Advertisement Option for IPv6 Multicast Prefixes  (Expired)
  This document defines a way to advertise IPv6 multicast prefix availability using Neighbor Discovery (RFC2461). This multicast RA option can be used by routers to announce a set of multicast prefixes that can be on the link to form new group addresses.
  Published: February 2005   Version: 0
• I-D: IPv6 multicast address assignment with DHCPv6  (Expired)
  This document proposes a simple solution to solve IPv6 multicast address assignment problem using the DHCPv6 protocol.
  Published: February 2005   Version: 1
• I-D: All DRs all RPs model  (Expired)
  This document defines a new model for IPv6 ASM (Any Source Multicast) where the Designated Router (DR) on each LAN can serve as a Rendezvous Point (RP) for group addresses formed from the RP address. This keeps group-to-RP mapping simple, while providing for multicast address allocation coordination to be kept within a subnet.
  Published: January 2005   Version: 0
• I-D: IPv6 Network Architecture Protection  (Expired)
  Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT.
  Published: January 2005   Version: 1
• I-D: v6tc Protocol Exploration  (Expired)
  This document aims to provide a rough sketch on different approaches to meet the zeroconf/assisted tunneling requirements for a simple IPv6-in-IPv4 tunnel set-up mechanism.
  Published: December 2004   Version: 0
• I-D: NAT and Firewall Traversal for HIP  (Expired)
  The Host Identity Protocol is a signaling protocol which adds another layer to the Internet model and establishes IPsec ESP SAs to protect subsequent data traffic. HIP also aims to interwork with middleboxes (such as NATs and Firewalls). This document investigates this aspect in more detail.
  Published: October 2004   Version: 3
• I-D: IPv6 Transition/Co-existence Security Considerations  (Expired)
  The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: Issues due to the IPv6 protocol itself, due to transition mechanisms, and due to the way in which IPv6 is being deployed.
  Published: October 2004   Version: 3
• I-D: Operational Considerations and Issues with IPv6 DNS  (Expired)
  This memo presents operational considerations and issues with IPv6 Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehaviour, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS.
  Published: October 2004   Version: 10
• I-D: Evaluation of IPv6 Auto-Transition Algorithm  (Expired)
  This memo evaluates a method called "auto-transition" to ensure that any device can obtain IPv6 connectivity at any time and whatever network is attached to, even if such network is connected to Internet only with IPv4 or already offers IPv6 but with poor performance. The algorithm looks for the best possible transition mechanism according to performance criteria information available as well as the scenario where the device is located. By implementing such auto-transition algorithm in either or both end nodes or middle boxes (CPEs), users could always obtain IPv6 connectivity with no human intervention. The document doesn't actually provides a complete solution, just an evaluation of the problem and the requirements towards a future documented solution.
  Published: October 2004   Version: 2
• I-D: Things to think about when Renumbering an IPv6 network  (Expired)
  This memo presents a summary of scenarios, issues for consideration and IPv6-specific tools for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. The document is not intended to be complete at the -00 phase, and will be enhanced as further operational experience is gathered.
  Published: October 2004   Version: 0
• I-D: Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks  (Expired)
  Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, including the most likely scenario of links running IPv6 in parallel with the existing IPv4 links in the enterprise. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link.
  Published: October 2004   Version: 2
• I-D: IPv4 and IPv6 Dual-Stack Issues for DHCPv6  (Expired)
  A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol (DHCP). The original version of DHCP [1] designed for IPv4 has now been complemented by a new DHCPv6 [4] for IPv6. This document describes issues identified with dual IP version DHCP interactions.
  Published: October 2004   Version: 2
• I-D: IPv6 Campus Transition Scenario Description and Analysis  (Expired)
  In this document we consider and analyse the specific scenario of IPv6 transition and deployment in a large department of a university campus network. The department is large enough to operate its own instances of all the conventional university services including (for example) web, DNS, email, filestore, interactive logins, and remote and wireless access. The scenario is a dual-stack one, i.e. transition to IPv6 means deploying IPv6 in the first instance alongside IPv4. This analysis will both identify the available (and still missing) components for IPv6 transition, and also test the applicability of the recently completed IPv6 Enterprise Network Scenarios document.
  Published: October 2004   Version: 1
• I-D: Analysis of IPv6 Tunnel End-point Discovery Mechanisms  (Expired)
  To be able to automate setting up IPv6-in-IPv4 tunnels, it is important to be able to automatically determine the tunnel end-point for the tunneling mechanism. This memo presents a short analysis and conclusions on the different approaches for discovering the IPv6 tunnel endpoint on a node.
  Published: July 2004   Version: 3
• I-D: Bootstrap Router (BSR) Mechanism for PIM  (Expired)
  This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol Independent Multicast protocol) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure.
  Published: July 2004   Version: 4
• I-D: DHCPv6 IPv4 Information Options  (Expired)
  To ease the management of a site, the Dynamic Host Configuration Protocol (DHCP) is often used. DHCP exists both for the Internet Protocol Version 4 (DHCPv4 for IPv4) and Version 6 (DHCPv6 for IPv6). To avoid possible pitfalls that occur if both DHCP versions are used and to avoid redundancy, IPv4 Information Options may be transmitted using DHCPv6 as described in this document. In dual-stack IPv4/IPv6 scenarios that employ DHCPv6, DHCPv4 can be completely replaced by using the DHCPv6 IPv4 Information Options.
  Published: February 2004   Version: 0
• I-D: Considerations for IPv6 Tunneling Solutions in Small End Sites  (Expired)
  Tunneling IPv6 packets over the IPv4 Internet played a major role in the early stages of IPv6 deployment. This was useful because in the early days the routers in the internet did not support IPv6. Nowadays, tunneling is used to get across legacy equipment and ISPs that do not support IPv6. Many different tunneling mechanisms have been invented. This document describes the drivers for IPv6 tunneling, the general architectures of existing mechanisms, and a set of desirable properties against which subsequent analysis of the mechanisms may be made. The document is aimed at small end sites that may typically utilise tunneling methods in an early IPv6 deployment.
  Published: October 2003   Version: 0
• I-D: IPv6 Implications for TCP/UDP Port Scanning  (Expired)
  The 128 bits of IPv6 address space is considerably bigger than the 32 bits of address space in IPv4. In particular, the IPv6 subnets to which hosts attach will by default have 64 bits of host address space. As a result, traditional methods of remote TCP or UDP port scanning to discover open or running services on a host will potentially become far less computationally feasible, due to the larger search space in the subnet. This document discusses that property of IPv6 subnets, and describes related issues for site administrators of IPv6 networks to consider.
  Published: October 2003   Version: 0
• I-D: Deprecating Site-Local Addresses  (Expired)
  This document describes the issues surrounding the use of IPv6 site - local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented.
  Published: August 2003   Version: 0
• I-D: IPv6 Flow Label Specification  (Expired)
  This document specifies the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, the requirements for IPv6 nodes forwarding labeled packets, and the requirements for flow state establishment methods. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.
  Published: April 2003   Version: 7
• I-D: IPv6 Site Multihoming: Now What?  (Expired)
  ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices cause a significant increase the routing table size, change rates and instability, the tragedy of the commons by encouraging selfish routing practices, the exhaustion of the 16-bit AS number space, and may collapse the Internet interdomain routing architecture. As there has been a desire to avoid similar problems as seen with IPv4, the use of similar techniques to achieve site multihoming has been prevented operationally in IPv6. However, the long effort to proceed with other IPv6 multihoming mechanisms has produced lots of heat but little light. This memo tries to list available techniques, split the organizations to different types to separately examine their multihoming needs, to look at the immediate and short-term solutions for these organization types, and to list a few immediate action items on how to proceed with IPv6 site multihoming.
  Published: April 2003   Version: 0
• I-D: Firewalling Considerations for IPv6  (Expired)
  There are quite a few potential problems regarding firewalling or packet filtering in IPv6 environment. These include slight ambiguity in the IPv6 specification, problems parsing packets beyond unknown Extension Headers and Destination Options, and introduction of end-to-end encrypted traffic and peer-to-peer applications. There may also be need to extend packet matching to include some Extension Header or Destination Option fields. This draft discusses these issues to raise awareness and proposes some tentative solutions or workarounds.
  Published: March 2003   Version: 1
• I-D: A View on IPv6 Transition Architecture  (Expired)
  The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches.
  Published: February 2003   Version: 0
• I-D: An IPv4 - IPv6 multicast gateway  (Expired)
  This document describes an IPv4 - IPv6 gateway solution that embeds all IPv4 multicast group addresses into IPv6, and allows IPv6 hosts to receive from and send to IPv4 multicast groups.
  Published: February 2003   Version: 0
• I-D: Multihoming Using IPv6 Addressing Derived from AS Numbers  (Expired)
  In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS-number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4.
  Published: January 2003   Version: 0
• I-D: RFC 3041 Considered Harmful  (Expired)
  The purpose of the privacy extensions for stateless address autoconfiguration [1] is to change the interface identifier (and the global-scope addresses generated from it) over time in order to make it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. Current Distributed Denial of Service (DDoS) [2] attacks employ forged source addresses which can also be in the same prefixes than the real addresses of the compromised nodes used for attacks. Indeed, network ingress filtering defeats DDoS using "random" forged source addresses. The issue developed in this document is that the behavior of a compromised node used as source in a DDoS attack with "in-prefix" spoofed source address and the behavior of nodes using temporary addresses at high rate can not be distinguished. This could make future defenses against DDoS attacks very hard.
  Published: January 2003   Version: 2
• I-D: Security of IPv6 Routing Header and Home Address Options  (Expired)
  All IPv6 nodes must be able to process Routing Header [IPV6] and Home Address [MIPV6] Options. With these, packet filter access lists can be tricked (among other things) as the destination and source addresses, respectively, are being rewritten as the packet traverses the network. Some of the security considerations of these features are analyzed, and a few possible solutions presented. It will be shown that with the current architecture, the network-based security does not seem to scale to the requirements of Mobile IPv6; it seems possible that unless security is taken seriously when implementing the nodes, the new Mobile IPv6 requirements might not be allowed to be used at all in some circumstances.
  Published: December 2002   Version: 3
• I-D: Moving from 6bone to IPv6 Internet  (Expired)
  Currently, IPv6 Internet is, globally considered, inseparable from the 6bone network. The 6bone has been built as a tighly meshed tunneled topology. As the number of participants has grown, it has become an untangible mess, hindering the real deployment of IPv6 due to low quality of connections. This memo discusses the nature and the state of 6bone/IPv6 Internet, points out problems and outlines a few ways to start fixing them; also, some rough operational guidelines for different-sized organizations are presented. The most important issues are: not offering transit to everyone and real transit operators being needed to take a more active role.
  Published: November 2002   Version: 1
• I-D: IPv6 Multicast Deployment Issues  (Expired)
  There are many issues concerning the deployment and implementation, and to a lesser degree, specification of IPv6 multicast. This memo describes known problems, trying to raise awareness. Currently, global IPv6 interdomain multicast is completely impossible except using SSM: there is no way to convey information about multicast sources between PIM RPs. Site-scoped multicast is also problematic when used alongside to global multicast because of that. A few possible solutions are outlined or referred to. In addition, an issue regarding link-local multicast-blocking Ethernet switches is brought up. Finally, a feature request for MLD snooping switches is noted.
  Published: November 2002   Version: 1

GGF Specifications

• GFD.40: Guidelines for IP version independence in GGF specifications
  This document serves two functions. Its motivation is to aid in the creation of IP-version independent specifications and consequently, in the transition of IPv4 to IPv6. First, it describes how to avoid IPv4 dependencies in GGF specifications. Secondly, it outlines new, IPv6-specific issues for application designers and implementers. It should be used by all GGF WGs and as a checklist for document approval.
  Published: 7 January 2005
• GFD.41: Survey of IPv4 Dependencies in GGF specifications
  This document is a survey of IPv4 dependencies on current Global Grid Forum (GGF) specifications. It is an informational document, intended to be used as a checklist for planning future specification revisions. Its motivation is to aid in the creation of IP-version independent specifications and consequently, in the transition of IPv4 to IPv6.
  Published: 26 November 2004