table of contents - ipv6 · ist-2001-34056 standardisation report issue 1.0 addressing key issues...
TRANSCRIPT
IST-2001-34056
Deliverable D5.1.4
"Standardisation Report" Contractual date of delivery to the European Commission:
April 2003
Actual date of delivery to the European Commission
April 2003
Editor(s) M. Ford (BT) Participant(s) BT, CRM Workpackage WP5 Title of Deliverable Standardisation Report Security Pub Deliverable Type R Version Issue 1 Number of pages 66
Abstract This deliverable details the key issues and references important documents in all areas of IPv6 technology standardisation.
Keywords IPv6, standards, IETF, 3GPP, RIR, RIPE, APNIC, ARIN
© 6LINK
IST-2001-34056 Standardisation Report Issue 1.0
Table of Contents Table of Contents ..........................................................................................................................2 Overview .........................................................................................................................................3 People & Process ...........................................................................................................................4 Addressing.......................................................................................................................................5 Autoconfiguration....................................................................................................................... 10 DNS .............................................................................................................................................. 16 IPv6 over Link Layers ................................................................................................................ 18 Multicast ....................................................................................................................................... 19 Routing ......................................................................................................................................... 22 Mobility......................................................................................................................................... 24 Multihoming ................................................................................................................................ 33 Network Management................................................................................................................ 36 API ................................................................................................................................................ 37 QoS ............................................................................................................................................... 39 Security ......................................................................................................................................... 40 Transition ..................................................................................................................................... 45 3GPP............................................................................................................................................. 52 RIR Developments ..................................................................................................................... 54 Miscellaneous............................................................................................................................... 55 Acronyms ..................................................................................................................................... 60 Appendix ...................................................................................................................................... 61
Please address comments and/or queries related to this document to the author, Mat Ford ([email protected]).
© 6LINK www.6link.org Page 2 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Overview This report attempts to capture the status of IPv6 technology standardisation in April 2003. It is primarily based on the proceedings of the 56th IETF meeting, but also includes updates on the activities of the Regional Internet Registries and 3GPP. The report is divided into various technology areas, and further subdivided into a discussion of the key issues and the new or actively developing standards in those areas.
This report only includes details of new or actively developing standards. Therefore, any standards mentioned are either new or have been updated since the previous issue, and the ‘Comments’ field of each entry clearly indicates which of these categories applies. The ‘Key Issues’ sections and ‘Overview’ sections are updated appropriately. An appendix lists details of the new and revised drafts included in this report.
N.B. If the document you want isn’t available at the URL presented herein, try increasing the version number as it has probably been revised since this document was published. A complete Internet Draft archive is available at http://www.watersprings.org.
Recent technical highlights include:
DHCPv6 has been accepted as a Proposed Standard
MobileIPv6 has completed IETF Last Call and is now with the IESG for publication as Proposed Standard
Ericsson have stated that they will not assert any patents they hold relating to draft-ietf-send-ipsec-00.txt should any part of that document be included in any SEND (Secure Neighbour Discovery) standard. It is hoped that Microsoft will make a similar statement soon.
The IPv6 Working Group meeting discussed deprecating IPv6 site-local addresses and showed a majority in favour (~100 hands versus ~20). This ‘consensus’ is now the subject of heated debate on the mailing list and has become the subject of an appeal. The exact meaning of 'deprecate' is to be defined.
Consensus was reached on 6bone shutdown planning. Cut-off for new allocations will be January 1st, 2004. Shutdown will be June 6th, 2006 (06/06/06).
The v6ops Working Group will develop an Applicability Statement for NAT-PT. There was split consensus on whether to move the existing Proposed Standard to Historic, leave it at PS, or to update it. Majority support was for leaving it at PS. There was some comment that 3GPP may modify their current dependence on NAT-PT.
The new IPv6 address allocation policy has led to a steep rise in allocations (even in the ARIN region).
© 6LINK www.6link.org Page 3 of 65
IST-2001-34056 Standardisation Report Issue 1.0
People & Process The ngtrans Working Group webpage has closed. Re-issued ngtrans drafts will have to be submitted as personal submissions until they are accepted by another working group.
The ipv6 Working Group updated charter has been approved by the IESG. DNS Discovery has been removed as a work item and will be handled by the dnsop Working Group.
Kurt Lindqvist has replaced Thomas Narten as co-chair of the multi6 Working Group.
An appeal to the IAB concerning the IPv6 Addressing Architecture document has been considered and the IAB, in upholding the appeal, has determined that the document is not clear enough to be published at Draft Standard. The IAB has recommended publication at Proposed Standard. A future version of the document may be accepted for publication as Draft Standard and the IAB has made suggestions concerning the areas of the document that need to be fixed. Further discussion will take place in the ipv6 Working Group.
Internet-Draft cut-off dates for the IETF57 meeting are:
June 23rd (0900hrs ET): Cut-off for Initial Submissions (new documents)
June 30th (0900hrs ET): FINAL Internet-Draft Cut-off
These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_57.html
© 6LINK www.6link.org Page 4 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Addressing
Key Issues
Site-local addresses A lengthy debate at the IPv6 Working Group meeting during IETF56 led to a consensus call on whether or not site-local addresses should be ‘deprecated’. A vote on the issue indicated a majority in favour of deprecation, although it is not completely clear what deprecation would entail. The Working Group did acknowledge an operational need for local-scope addresses and will attempt to gain consensus on the requirements for these addresses before moving forward with an alternative technological solution.
Having said that, the consensus call referred to above is now the subject of an appeal and, as this is a highly contentious issue, the exact direction of the Working Group is hard to predict at this time.
IPv6 Addressing Architecture The revised IPv6 Addressing Architecture has been published as Proposed Standard RFC 3513. This document was being prepared for publication as a Draft Standard, but that is now delayed pending fixes to the document to address the substance of the successful appeal to the IAB made by Robert Elz.
Standards Development Title A Flexible Method for Managing the Assignment of Bits of an IPv6
Address Block
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ipaddressassign-06.txt
Abstract This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC1219 and can be used for IPv6 assignments.
Comment Revised.
© 6LINK www.6link.org Page 5 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title An IPv6 Provider-Independent Global Unicast Address Format
URL http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-04.txt
Abstract This document defines an IPv6 Provider-Independent global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [2] and the "IPv6 Addressing Architecture" [3]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber.
Comment Revised.
Title Application and Use of the IPv6 Provider Independent Global Unicast Address Format
URL http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-04.txt
Abstract This document discusses the expected use of the Provider Independent address format discussed in the companion document GEO [2] in the Internet. In addition to covering implementations where it adds value in managing the growth of the Internet routing tables, the document will discuss implementations that should be avoided due to the negative impact on the routing tables.
Comment Revised.
Title Internet Protocol Version 6 (IPv6) Addressing Architecture
URL http://www.ietf.org/rfc/rfc3513.txt
Abstract This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC-2373 ‘IP Version 6 Addressing Architecture’.
Comment Adopted as a Standards Track RFC (Proposed Standard). May be suitable for publication as Draft Standard after fixes to address the substance of the appeal made by Robert Elz to the IAB.
© 6LINK www.6link.org Page 6 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title The Impact of Site-Local Addressing in Internet Protocol, Version 6 (IPv6)
URL http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt
Abstract Internet Protocol, Version 6 (IPv6) introduces a scoped unicast addressing architecture, including the concept of site-local addressing. Although site-local addresses were originally defined for use in networks that were not yet connected to the Internet, there has been work underway for several years to expand the use of site-local addresses to globally connected IPv6 networks and nodes. The use of site-local addresses on globally connected networks and nodes raises complex technical issues for many parts of the TCP/IP protocol suite. Many of these issues are caused by the fact that IPv6 sites are private address spaces, and site-local addresses are unreachable or ambiguous outside of their originating site. Site-local addresses also add significant complexity at the IP layer and at other layers of the protocol stack. Although there are several benefits attributed to site-local addressing, some of those benefits can be more easily achieved through less problematic mechanisms.
Comment This is a new draft since the last report.
Title Moderate Use Case for IPv6 Site-Local Addresses
URL http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt
Abstract This internet draft describes the moderate use case for IPv6 Site-Local Addresses.
Comment This is a new draft since the last report.
Title IPv6 Global Unicast Address Format
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt
Abstract RFC2374 "An IPv6 Aggregatable Global Unicast Address Format" defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 7 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Documentation Address
URL http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-prefix-00.txt
Abstract To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link- local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:0DB8::/32 as a reserved prefix for use in documentation. This prefix has been assigned by the Asia Pacific Network Information Centre (APNIC) for this purpose, on behalf of the Regional Internet Registries.
Comment This is a new draft since the last report.
Title RFC 3041 Considered Harmful
URL http://www.ietf.org/internet-drafts/draft-dupont-ipv6-rfc3041harmful-02.txt
Abstract 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.
Comment Revised.
Title Organization Zone Prefix Length Discovery
URL http://www.ietf.org/internet-drafts/draft-zill-ipv6wg-zone-prefixlen-00.txt
Abstract This document specifies an extension to IPv6 Neighbor Discovery which allows nodes to discover the prefix length of the organizational administrative zone associated with an advertised prefix.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 8 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Site-Local Requirements
URL http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-00.txt
Abstract This memo will discuss the requirements for the Site-Local address range.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 9 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Autoconfiguration
Key Issues
DHCPv6 DHCPv6 has been accepted as a Proposed Standard and several of the options have now passed Last Call.
Standards Development Title IPv6 Router Advertisement DNS Resolver Option
URL http://www.ietf.org/internet-drafts/draft-beloeil-ipv6-dns-resolver-option-01.txt
Abstract This document defines the DNS resolver (DNSR) option used to advertise on a link IPv6 addresses of DNS resolvers. The DNSR option, which lists the IPv6 addresses of DNS resolvers that all nodes of the link may use to resolve name or address, is attached to IPv6 Neighbor Discovery Router Advertisement messages that are sent across a link. This document specifies the process used by a host to decide how to configure the IPv6 addresses of DNS resolvers that the host could use in IPv6 networks. This document defines the mechanism by which a node processes the DNSR option and updates valid IPv6 addresses of DNS resolvers.
Comment Revised.
Title Optimistic Duplicate Address Detection
URL http://www.ietf.org/internet-drafts/draft-moore-ipv6-optimistic-dad-02.txt
Abstract Optimistic DAD is an interoperable modification of the existing IPv6 Neighbour Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case without greatly increasing disruption in the less likely failure case.
Comment Revised.
© 6LINK www.6link.org Page 10 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-28.txt
Abstract The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC2462), and can be used separately or concurrently with the latter to obtain configuration parameters.
Comment Has been accepted as a Proposed Standard, several options passed last call, interoperability tests at TAHI, Connectathon - some specification issues identified - clarifications published in draft-ietf-dhc-dhcpv6-interop-01.txt (see below) will be included in DHCPv6 RFC.
Title Results from Interoperability Tests of DHCPv6 Implementations
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-interop-01.txt
Abstract This document publishes issues with the DHCPv6 protocols specifications, based on the results of interoperability testing among several implementations.
Comment This is a new draft since the last report. Clarifications published in this document will be included in the eventual DHCPv6 RFC (see above).
Title Requirements for IPv6 prefix delegation
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt
Abstract This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site").
Comment Revised. Needs further revisions to remove L2 specific text and to include solution for shared media, e.g. powerline, cable.
Title Performing DNS queries via IP Multicast
URL http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-01.txt
Abstract As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up host names and similar DNS resource record data types, in the absence of a conventional managed DNS server, is becoming essential.
Comment This important technology for autoconfiguration contains some IPv6 specific considerations.
© 6LINK www.6link.org Page 11 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Deployment using Device ID
URL http://www.ietf.org/internet-drafts/draft-park-ipv6-deployment-00.txt
Abstract This document presents a new configuration of EUI-64 format through defined Device ID for identification and characteristic of all Devices in unmanaged network especially "Home network". Because of configured Device ID, all Devices in network must be classified and communicated each other. The main purpose of this document is to deploy IPv6 easily and widely.
Comment This is a new draft since the last report
Title IPv6 Domain Name Auto-Registration (6DNAR)
URL http://www.ietf.org/internet-drafts/draft-park-6dnar-01.txt
Abstract This document proposes automatic configuration of IPv6 network using Domain Name Auto-Registration(called 6DNAR). 6DNAR allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAR function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAR don't change any existing DNS system.
Comment This is a new draft since the last report
Title Domain Name Auto-Registration for Plugged-in IPv6 Nodes
URL http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt
Abstract This document describes a scheme of "Domain Name Auto-Registration for Plugged-in IPv6 Nodes" mechanism that makes it possible to register both regular and inverse domain name information of plugged-in IPv6 nodes to DNS servers automatically.
Comment This draft has been adopted as a Working Group work item and has been through a Working Group Last Call process with a lot of negative comment.
Title DNS Configuration options for DHCPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt
Abstract This document describes DHCPv6 options for passing a list of available DNS resolvers and a domain search list to a client.
Comment Revised taking account of comments received during Working Group Last Call in ipv6, dnsext and dhc Working Groups.
© 6LINK www.6link.org Page 12 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Prefix Options for DHCPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt
Abstract The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.
Comment Revised. Passed ipv6 wg and dhc wg Last Call. Bake-offs at tahi#4 and connectathon 2003. Will go to IETF Last Call.
Title Time Configuration Options for DHCPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt
Abstract This document describes the options for Time related configuration information in DHCPv6: NTP Servers and Timezone specifier.
Comment Revised.
Title NIS Configuration Options for DHCPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt
Abstract This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name.
Comment Revised.
Title Client Preferred Prefix option for DHCPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-01.txt
Abstract This document describes the Client Preferred Prefix option by which the client can specify its preferred prefixes on which the addresses need to be allocated by the server.
Comment Revised.
© 6LINK www.6link.org Page 13 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title A Guide to Implementing Stateless DHCPv6 Service
URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-00.txt
Abstract Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service.
Comment This is a new draft since the last report.
Title Site Specific Options for DHCP for IPv6
URL http://www.ietf.org/internet-drafts/draft-volz-dhc-dhcpv6-site-options-00.txt
Abstract This document specifies that a portion of the DHCP for IPv6 [DHCPv6] 16-bit option space is reserved for site-specific options. Site-specific options are to be used for site specific needs and MUST NOT be used for public (IANA assigned) or vendor specific options.
Comment This is a new draft since the last report.
Title IPv6 Router Advertisement based DNS Autoconfiguration
URL http://www.ietf.org/internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt
Abstract This document specifies the steps a node takes in deciding how to autoconfigure its domain name per interface in IP version 6 and the address of recursive DNS server. The autoconfiguration process includes a node's creating a domain name for its global address, verifying the uniqueness of the name in the domain where it is placed and registering both the regular domain name and inverse domain name information of the node with DNS server automatically. Also, it autoconfigures the address of recursive DNS server for DNS name resolution.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 14 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Extensions for DNS Plug and Play
URL http://www.ietf.org/internet-drafts/draft-park-ipv6-extensions-dns-pnp-00.txt
Abstract This document proposes automatic configuration of domain name (FQDN) for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as a part of IPv6 plug and play feature. 6DNAC allows the automatic registration of domain name and corresponding IPv6 Addresses with the DNS server. In order to provide 6DNAC function, Neighbor Discovery Protocol [2461] will be used. Moreover, 6DNAC does not require any changes to the existing DNS system.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 15 of 65
IST-2001-34056 Standardisation Report Issue 1.0
DNS
Key Issues None.
Standards Development Title Linklocal Multicast Name Resolution (LLMNR)
URL http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-17.txt
Abstract Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a Domain Name Service (DNS) server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache.
Comment Substantially revised
Title IPv6 DNS transition issues
URL http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-02.txt
Abstract This memo summarizes DNS related issues when transitioning a network to IPv6. Consensus and open issues are presented.
Comment Revised to address comments raised during IETF55 meeting and to merge text from other drafts. Remaining open issues are 6to4 reverse DNS section and pre-population in the reverse DNS tree (wildcard? synthesis? dynamic DNS update?).
Title DNS Extensions to support IP version 6
URL http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc1886bis-02.txt
Abstract This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. This Document combines RFC1886 and changes to RFC 1886 made by RFC 3152, obsoleting both. Changes mainly consist in replacing the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
Comment Revised.
© 6LINK www.6link.org Page 16 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Dynamic reverse DNS for IPv6
URL http://www.ietf.org/internet-drafts/draft-durand-dnsop-dynreverse-00.txt
Abstract This document describes a method to dynamically generate PTR records and corresponding A or AAAA records when the reverse path DNS tree is not populated. A special domain dynrev.arpa. is reserved for that purpose.
Comment This is a new draft since the last report. Discussion on whether to adopt as a work item is taking place on the mailing list.
© 6LINK www.6link.org Page 17 of 65
IST-2001-34056 Standardisation Report Issue 1.0
IPv6 over Link Layers
Key Issues None.
Standards Development Title IP Version 6 over MAPOS
URL http://www.ietf.org/internet-drafts/draft-ogura-ipv6-mapos-02.txt
Abstract Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over SONET/SDH. This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of forming IPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages.
Comment Revised.
Title IP encapsulation and address resolution over InfiniBand networks
URL http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt
Abstract This document specifies the frame format for transmission of IP and ARP packets over InfiniBand networks. Unless explicitly specified, the term 'IP' refers to both IPv4 and IPv6. The term 'ARP' refers to all the ARP protocols/op-codes such as ARP/RARP. This document also describes the method of forming IPv6 link-local addresses, and the content of the source/target link layer address option used in Neighbor solicitation and advertisement, router advertisement, router redirect and router solicitation on IPv6 over InfiniBand.
Comment Revised.
© 6LINK www.6link.org Page 18 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Multicast
Key Issues None.
Standards Development Title Embedding the Address of RP in IPv6 Multicast Address
URL http://www.ietf.org/internet-drafts/draft-savola-mboned-mcast-rpaddr-02.txt
Abstract As has been noticed, there is exists a huge deployment problem with global, interdomain IPv6 multicast: PIM Renzesvous Points (RPs) have no way of communicating the information about multicast sources to other multicast domains, as there is no MSDP, and the whole interdomain Any Source Multicast model is rendered unusable; SSM avoids these problems. This memo outlines a way to embed the address of the RP in the multicast address, solving the interdomain multicast problem. The problem is three-fold: specify an address format, adjust the operational procedures and configuration if necessary, and modify PIM implementations of those who want to join or send to a group (Designated Routers) or provide one (Rendezvous Points). In consequence, there would be no need for interdomain MSDP.
Comment Revised.
Title IGMPv3/MLDv2 and Multicast Routing Protocol Interaction
URL http://www.ietf.org/internet-drafts/draft-ietf-magma-igmpv3-and-routing-04.txt
Abstract The definitions of IGMPv3 and MLDv2 require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates multicast routing protocols to manage and utilize the information. This document will describe how multicast routing protocols will interact with these source-filtering group management protocols.
Comment Ready for WG Last Call for publication as Informational.
© 6LINK www.6link.org Page 19 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Considerations for IGMP and MLD snooping switches
URL http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-06.txt
Abstract This memo describes the requirements for IGMP- and MLD-snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. Interoperability issues that arise between different versions of IGMP are not the focus of this document. Interested readers are directed to [IGMPv3] for a thorough description of problem areas.
Comment Revised.
Title Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery
URL http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-02.txt
Abstract This draft describes a possible optimization to Duplicate Address Detection (DAD) which can be used to successfully terminate DAD early, based on the presence of listeners on the link-scope solicited nodes multicast address.
Comment Revised.
Title Source Address Selection for Multicast Listener Discovery Protocol (RFC 2710)
URL http://www.ietf.org/internet-drafts/draft-ietf-magma-mld-source-05.txt
Abstract It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery messages when a node is performing stateless address autoconfiguration. This memo is intended to clarify the rules on selecting an IPv6 address to use for MLD messages. This document updates RFC 2710.
Comment Revised.
© 6LINK www.6link.org Page 20 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Using IGMPv3 and MLDv2 For Source-Specific Multicast
URL http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3-ssm-04.txt
Abstract The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-Specific Multicast (SSM) is a particular form of multicast in which a network multicast transmission is bound to a specific source. This document describes clarifications of and modifications to the behaviour of IGMPv3 and MLDv2 to accomodate source-specific multicast.
Comment Revised.
Title Source-Specific Multicast for IP
URL http://www.ietf.org/internet-drafts/draft-ietf-ssm-arch-02.txt
Abstract IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for Source-Specific Multicast use. It defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension.
Comment Revised.
© 6LINK www.6link.org Page 21 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Routing
Key Issues None.
Standards Development Title Traffic Engineering Extensions to OSPF version 3
URL http://www.ietf.org/internet-drafts/draft-ishiguro-ospf-ospfv3-traffic-02.txt
Abstract This document describes extensions to the OSPF version 3 to support intra-area Traffic Engineering [RFC2702]. The OSPFv3 protocol is specified in [RFC2740]. This document expands [OSPFV2-TE] to make both IPv4 and IPv6 network applicable. New sub-TLVs are defined to support IPv6 network. Use of these new sub-TLVs are not limited in OSPF version 3. They can be used in OSPF version 2.
Comment Revised.
Title Routing IPv6 with IS-IS
URL http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-05.txt
Abstract This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes 2 new TLVs, a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol.
Comment Revised.
Title Support of address families in OSPFv3
URL http://www.ietf.org/internet-drafts/draft-mirtorabi-ospfv3-af-00.txt
Abstract This document describes an extensible mechanism to support Address Families in OSPFv3. One undefined field in the Router-LSA is used to define the address-families on a link. A router may participate in multiple address families on different links. This information needs to be advertised so that only applicable link are used in the SPF calculation when building an address family specific shortest path tree.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 22 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Protocol Topology Support for IS-IS
URL http://www.ietf.org/internet-drafts/draft-noguchi-isis-protocol-topology-01.txt
Abstract RFC 1195 [1] documents a dual routing protocol that can be used to route both CLNP and IPv4, that is Integrated IS-IS. [2] adds functionality to Integrated IS-IS so that it supports IPv6. RFC 1195 [1] places topological restrictions on networks that are routed using Integrated IS-IS, specifically, that every router in a level-1 area must be capable of all network layer protocols that are present in that area, and every routers in a level-2 area must be capable of all network layer protocols that are present in the whole IS-IS routing domain. The mechanism described in this document enables a single IS-IS routing domain to support different network layer protocol topologies by maintaining separate SPF trees for each network layer protocol. Furthermore, it no longer requires a router's protocol support capability to be identical for all interfaces on the router.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 23 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Mobility
Key Issues
MobileIPv6 The MobileIPv6 document has passed IETF Last Call with a number of comments and is now with the IESG who have also issued detailed comments. Connectathon testing has also highlighted some minor issues. Most of these have been addressed, and the few remaining open issues are detailed on the issues register web page (see below).
MobileIPv6 Working Group Split A BOF meeting during IETF56 discussed the potential work items for a future MobileIPv6 working group (i.e. separate from any working group addressing Mobile IPv4). A short list of these is:
Optimisations to the base protocol
Reliability of Home Agents Bbootstrapping MIPv6 SAs Alternatives to Return-Routability-based Route Optimisation Hierarchical MIPv6 Fast handovers MIBs
The group would also seek to learn from implementation experience and interop events to identify and fix issues in the base protocol.
In addition, a parallel research community will be set up in the IRTF to create a home for the more long-term IP mobility research subjects and to do work on simulation of mobility models and protocols. Study of radical new mobility architectures would be explicitly out-of-scope for the IRTF Mobility Group, but not for the IRTF in general (e.g. as part of the Routing Research Group).
Discussions about whether to further split the work into a group exclusively focussed on the base specification and another group on the optimisations did not show consensus either way.
© 6LINK www.6link.org Page 24 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Standards Development Title Localized Key Management for AAA in MobileIPv6
URL http://www.ietf.org/internet-drafts/draft-mun-aaa-localkm-mobileipv6-01.txt
Abstract This document describes a way to distribute secure key for optimizing AAA authentication procedure while a mobile node is away from it's home. The AAA infrastrucrue is used as an underlying framework which enables a Mobile-IPv6 node to get an global authentication by identifying it with an unique identifier NAI. The Diameter messages are exchanged to transfer information of mobile node between home and foreign AAA servers. The steps to complete an authentication procedure for mobile node in the visited link may be reduced by delegating the role for generating and synchronizing keys to AAA server in the visited domain. The implications to existing entities supporting mobility such as attendant, AAA server in home and visited domain are discussed. The delegation is introduced and the related security issues are pointed out.
Comment Revised.
Title Diameter Mobile IPv6 Application
URL http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-03.txt
Abstract Mobile IPv6 capable mobile nodes can roam between networks that belong to their home service provider as well as others. Roaming in foreign networks is enabled as a result of the service level and roaming agreements that exist between operators. One of the key protocols that allows this kind of a roaming mechanism to be enabled is Diameter. This Internet Draft specifies a new application to Diameter that enables Mobile IPv6 roaming in networks other than its home.
Comment Revised.
© 6LINK www.6link.org Page 25 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Fast Handovers for Mobile IPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-06.txt
Abstract Mobile IPv6 describes how a Mobile Node can maintain connectivity to the Internet when it changes its Access Router for another, a process referred to as handover. During this process, there is a time period when the Mobile Node is unable to send or receive IPv6 packets both due to link switching delay and IP protocol operations. This time period is referred to as handover latency. In many instances, the handover latency resulting from standard Mobile IPv6 handover procedures could be greater than what is acceptable to support real-time or delay sensitive traffic. Furthermore, reducing the handover latency could be beneficial to non real-time, throughput-sensitive applications as well. The intent of this document is to describe protocol enhancements to reduce handover latency due to IP protocol operations as small as possible in comparison to the inevitable link switching latency.
Comment Revised. Main outstanding issue is how to secure the Fast Binding Update that relies on a trust relationship between the MN and the PAR. Cryptographically-Generated Addresses (CGA) and Purpose-Built Keys (PBK) could be used if the security holes inherent in those solutions were acceptable.
Title Mobility Support in IPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-21.txt
Abstract This document specifies the operation of the IPv6 Internet with mobile computers. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary can communicate with mobile nodes.
Comment Revised. The few remaining issues are detailed in the MobileIPv6 Issue List (see below).
© 6LINK www.6link.org Page 26 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Mobile IPv6 Issue List
URL http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html
Abstract This page provides a list of known issues that wait resolution in MIPv6. New issues can be submitted by sending an email to the WG mailing list, with a ‘New Issue:’ appearing in the Subject line.
Comment Revised.
Title IPv6 Fast Router Advertisement
URL http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-03.txt
Abstract This document specifies an amendment to the router solicitation handling procedures in RFC 2461 that allow for improved default router aquisition performance when an active IP host moves from one subnet to another.
Comment Revised.
Title Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents
URL http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-ha-ipsec-04.txt
Abstract Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
Comment Revised. This document is ready for IESG Last Call.
Title Mobile IPv6 Authentication, Authorization, and Accounting Requirements
URL
Abstract This document describes the motivation why Diameter support for Mobile IPv6 is required and needs to be developped. It analyses the requirements expressed in RFC 2977 which was written both for MIPv4 and MIPv6; and it finally updates the IPv6 requirements for the AAA support for Mobile IPv6 to reflect the latest modifications and evolution of the Mobile IP, AAA and other relevant working groups.
Comment Revised.
http://www.ietf.org/internet-drafts/draft-le-aaa-mipv6-requirements-02.txt
© 6LINK www.6link.org Page 27 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Dynamic Binding Update Using AAA
URL http://www.ietf.org/internet-drafts/draft-mun-aaa-dbu-mobileipv6-00.txt
Abstract This document describes the procedure of how dose the Mobile Node(MN) exchange the messages with it's Corresponeant Node(CN) by using the secure communication platform, the AAA infrastructure that consists of the many AAA servers in different domains when the MN is about to enter the visited link.
Comment This is a new draft since the last report.
Title Enhanced Forwarding from Previous Care-of Address for Fast Mobile IPv6 Handovers (eFWD)
URL http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-01.txt
Abstract This memo introduces a low latency and low loss handover protocol that enhances the performance of forwarding from previous care-of address for Mobile IPv6, namely eFWD. The eFWD allows a mobile node to control and initiate creation of a bi-directional tunnel between the old and the new access routers subsequent to link layer handover. The eFWD handover reduces IP handover latency by eliminating new care-of address acquisition time and by identifying new access router information in advance utilizing Candidate Access Router Information Discovery (CARID) process detailed in this memo. The eFWD protocol removes extra burden on link layer by eliminating any requirement on pre-triggers.
Comment This is a new draft since the last report.
Title Network Mobility Support Requirements
URL http://www.ietf.org/internet-drafts/draft-ietf-nemo-requirements-00.txt
Abstract Network mobility arises when an entire network changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is viewed as a unit and is connected to the global Internet by one or more mobile routers. In contrast with host mobility support which aims at providing continuous Internet connectivity to mobile hosts only, network mobility support is to provide continuous Internet sessions not only to the mobile router connecting the mobile network to the global Internet, but also to nodes behind the mobile router. The purpose of this document is to list the requirements that must be met by network mobility support solutions in IPv6.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 28 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Multiple Care-of Address Registration on Mobile IPv6
URL http://www.ietf.org/internet-drafts/draft-wakikawa-mobileip-multiplecoa-00.txt
Abstract This document describes how to manage and register multiple care-of addresses which are assigned to either single or multiple network interfaces with a single home address on Mobile IPv6. Associating multiple care-of addresses with a home address enable durable Internet connectivity [7] [1] [8]. For example, when a Mobile Node (MN) loses its Internet connectivity at one of the interface, it can use the second interface as a backup interface and still keep connectivity to the network. In addition, the MN can send each communication flow to a distinct network interface. This provides efficient network bandwidth consumption. A user can select the most suitable network interface per application.
Comment This is a new draft since the last report.
Title The Autoconfiguration of Recursive DNS Server and the Optimization of DNS Name Resolution in Hierarchical Mobile IPv6
URL http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-00.txt
Abstract This document provides the mechanism for the autoconfiguration of recursive DNS server in mobile node and the optimization of DNS name resolution in the hierarchical mobile IPv6 networks. Whenever the mobile node moves into a new MAP domain, the region managed by another MAP, in the hierarchical mobile IPv6 networks, it detects the addresses of recursive DNS servers which are placed in the region and replaces the old ones with the new ones for DNS name resolution. This allows the time for DNS name resolution much reduced by using the nearest DNS recursive server which exists in the region. Therefore, the mechanism of this document can optimize the DNS name resolution.
Comment This is a new draft since the last report. Further additions and extension to MobileIPv6 need to be considered.
© 6LINK www.6link.org Page 29 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks
URL http://www.ietf.org/internet-drafts/draft-paultan-seamless-ipv6-handoff-802-00.txt
Abstract To achieve seamless layer 3 handover, mobile nodes must be able to perform movement detection and neighborhood candidate access routers discovery quickly and efficiently. In this document, we present a conceptual overview on how to extend the IEEE 802.11 Management frames to carry extensible application-specific Information Element, which allow access points to advertise the capabilities information of its associated network/provider and to improve movement detection. We believe that mobile nodes can thus dynamically discover neighboring candidate access routers or networks more quickly and efficiently, and also to obtain valuable capabilities information so as to select the 'best' target access router to initiate seamless handover.
Comment This is a new draft since the last report.
Title SIM Authentication over IPv6 (SIM6)
URL http://www.ietf.org/internet-drafts/draft-kniveton-sim6-02.txt
Abstract Providing an existing scalable authorization infrastructure for mobile nodes is needed for IPv6-based mobility. SIM Authentication provides a protocol for authenticating and authorizing services. It uses an authorizing home domain defined by the Subscriber Identity Module (SIM). The protocol is an Internet Control Message Protocol for IPv6 (ICMPv6) [17] extension. It can leverage the existing SIM authorization infrastructure for automatic bootstrapping of security association between the mobile node and a service, where the service can be e.g. authorized last-hop VPN setup for network access or Mobile IPv6 mobile-home security association setup.
Comment Revised.
Title Local Key Exchange for Mobile IPv6 Local Binding Security Association
URL http://www.ietf.org/internet-drafts/draft-liu-mobileip-lke-01.txt
Abstract This document describes a key management protocol for a mobile computer to securely obtain keying material with an access router in a visited link for use as the local binding security association with the router. The protocol enables an IPv6 node to utilize the access router as its temporary home agent and continue to receive packets destined to its care-of address with the temporary home agent as well as to send packets from this care-of address when the nodes change its access router. To support this operation, a few new mobility headers and Neighbor Discovery options are defined. All IPv6 nodes MAY support this protocol.
Comment Revised.
© 6LINK www.6link.org Page 30 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Localized Mobility Management Requirements
URL http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-03.txt
Abstract This document describes requirements for Localized Mobility Management (LMM) for Mobile IP and Mobile Ipv6 protocols. These requirements are intended to guide the design of a protocol specification for LMM. Localized Mobility Management, in general, introduces enhancements to Mobile IPv4 and Mobile IPv6 to reduce the amount of latency in binding updates sent to the Home Agent and, for route-optimization, Correspondent Nodes, upon Care of Address change. In addition, LMM seeks to reduce the amount of signaling over the global Internet when a mobile node traverses within a defined local domain. The identified requirements are essential for localized mobility management functionality. They are intended to be used as a guide for analysis on the observed benefits over the identified requirements for architecting and deploying LMM schemes.
Comment Revised.
Title Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)
URL http://www.ietf.org/internet-drafts/draft-petrescu-nemo-mrha-02.txt
Abstract This document describes several issues relevant to the design of a network mobility support solution that relies on the bi-directional tunnel between Mobile Router and Home Agent, with Mobile IP. Examples of issues are: conflicting Mobile IP and RIPng/OSPF requirements on link-local addresses, HA/BR co-location, and "cross-over" tunnels.
Comment Revised.
Title IPv4 traversal for MIPv6 based Mobile Routers
URL http://www.ietf.org/internet-drafts/draft-thubert-nemo-ipv4-traversal-00.txt
Abstract Since IPv6 connectivity is not yet broadly available, there is a need in NEMO for a simple technology that allows a MIPv6 based Mobile Router to roam over IPv4 networks. The Doors Protocol proposed in this memo allows an arbitrary Mobile Node to roam even within private IPv4 address spaces, across both Network and Port Address Translations, in order to cope with existing of deployments of technologies such as GPRS.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 31 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Mobile Network Prefix Delegation extension for Mobile IPv6
URL http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt
Abstract This draft proposes a dynamic Mobile Network Prefix (MNP) delegation extension for Mobile IPv6 protocol to enable MNP delegation for mobile networks. A MNP is an IPv6 prefix used in a mobile network. The extension supports dynamic delegation, return, refreshing and updating operations related to MNP delegation operations between a Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). This extension is proposed, because there is a lack for a dynamic MNP delegation protocol related to mobile networks, and currently MNPs have to be assigned statically to enable mobile networking.
Comment This is a new draft since the last report.
Title Context Transfer and Fast Mobile IPv6 Interactions in a Layer-2 Source-Triggered Anticipative Handover
URL http://www.ietf.org/internet-drafts/draft-rjaya-ct-fmip6-l2st-ant-ho-00.txt
Abstract This draft was submitted to obtain comments for an experimental work in progress. It presents Fast Mobile IPv6 and Context Transfer interactions for a specific case of contextful, anticipative, network controlled and Layer-2 source-triggered IPv6 handover where one or more candidate access routers can be identified for selection as target.
Comment This is a new draft since the last report.
Title Fast Handover Agent (FHA) for Fast Router Discovery in FMIPv6
URL http://www.ietf.org/internet-drafts/draft-park-fasthandover-agent-fmipv6-00.txt
Abstract This document describes a new entity "Fast Handover Agent (FHA)", which can be used for fast router discovery and configuration in FMIPv6. The FHA is deployed to provide the fast RA for Mobile Nodes entering a new IP network, without any modification of existing FMIPv6 procedures.
Comment This is a new draft since the last report.
Title Preconfigured Binding Management Keys for Mobile IPv6
URL http://www.ietf.org/internet-drafts/draft-perkins-mobileip-precfg-kbm-00.txt
Abstract A mobile node and a correspondent node may preconfigure a Binding Management Key for authorizing Binding Updates.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 32 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Multihoming
Key Issues
No meetings There was, once again, no multi6 Working Group meeting at IETF56. There were ipv6mh meetings however, and mailing list activity has been substantial for both groups. There still appears to be a lack of consensus as to the requirements for work in this area, and it is not yet clear whether there has been sufficient progress to warrant an official multi6 meeting at IETF57.
Standards Development Title Multihoming Using IPv6 Addressing Derived from AS Numbers
URL http://www.ietf.org/internet-drafts/draft-savola-multi6-asn-pi-00.txt
Abstract 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.
Comment This is a new draft since the last report.
Title Application of the MIPv6 protocol to the multi-homing problem
URL http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mnm-00.txt
Abstract This note attempts to describe how to apply the MIPv6 protocol to provide fault tolerance to transport layer connections established between a multi-homed host and other hosts in the Internet. Specifically, this note addresses the usage of MIPv6 signaling messages to convey information about alternative address to be used when an outage occurs. Additionally, possible mechanisms to detect failures affecting the currently used path are explored.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 33 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title A road-map for multihoming in IPv6
URL http://www.ietf.org/internet-drafts/draft-kurtis-multi6-roadmap-00.txt
Abstract IPv6 was decided as the replacement to the widely deployed IPv4 in 1992. The new protocol was designed to meet a number of criteria that at that time was seen as the failures of IPv4, such as security and limited address space. IPv6 meet these needs, but it fails to meet other needs of the Internet of today such as scalable solutions for multihoming and portable address space for end-sites. The effects of the lack of scalable solutions to this is widely documented. In order to solve the multihoming scalability problems, the multi6 working group was created in the IETF. This group have so far not yet produced any documents as it has been hard to find consensus on even the most basic documents such as requirements. Multi6 have also suffered from problems reaching consensus on what type of solution will be required moving forward, and the attempt of trying to come up with a 'fit-all' solution from day one. This document tries to outline steps that could be taken to better understand the problem and what steps could be taken as we bit by bit tries to address the problem.
Comment This is a new draft since the last report.
Title Goals for IPv6 Site-Multihoming Architectures
URL http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-05.txt
Abstract Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. This document outlines a set of goals for proposed new IPv6 site-multihoming architectures.
Comment Revised.
© 6LINK www.6link.org Page 34 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Site Multihoming: Now What?
URL http://www.ietf.org/internet-drafts/draft-savola-multi6-nowwhat-00.txt
Abstract 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.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 35 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Network Management
Key Issues MIB documents still require a lot of peer review.
Standards Development Title Management Information Base for the Transmission Control Protocol
(TCP)
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-02.txt
Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) [RFC793] in an IP version independent manner.
Comment Revised.
Title Management Information Base for the Internet Protocol (IP)
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-02.txt
Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465 and 2466.
Comment Revised.
© 6LINK www.6link.org Page 36 of 65
IST-2001-34056 Standardisation Report Issue 1.0
API
Key Issues
Basic API The revised Basic API for IPv6 has been published as Informational RFC 3493 (obsoletes RFC2553)
Standards Development Title Basic Socket Interface Extensions for IPv6
URL http://www.ietf.org/rfc/rfc3493.txt
Abstract The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document.
Comment Revised and published as Informational RFC. Obsoletes RFC2553.
Title Advanced Sockets API for IPv6
URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-09.txt
Abstract This document provides sockets APIs to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 2553. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path MTU information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable.
Comment Revised. Has been approved by the IESG for publication as an Informational RFC.
© 6LINK www.6link.org Page 37 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Socket API for source address selection
URL http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-00.txt
Abstract The IPv6 default address selection document describes the rules for selecting default source address by the system and indicates that the applications should be able to reverse the sense of system preference of source address selection for that application through possible API extensions. However, no such socket APIs exist in the basic or advanced IPv6 socket API documents. Hence this document specifies socket level options to prefer a particular source address as per the choice of the applications. It also discusses implications on the name-to-address translation API that performs part of the default address selection. The socket APIs described in this document will be particularly useful for Mobile IPv6 enabled applications and other IPv6 applications which want to choose between temporary and public addresses, CGA (cryptographically generated addresses) and non-CGA addresses etc..
Comment This is a new draft since the last report.
Title Extension to Sockets API for Mobile IPv6
URL http://www.ietf.org/internet-drafts/draft-chakrabarti-mobileip-mipext-advapi-00.txt
Abstract This document describes data structures and API support for Mobile IPv6 as an extension to Advanced Socket API support for IPv6. Mobility Support in IPv6 introduces mobility protocol header for IPv6. It is expected that future Mobile IPv6 applications and implementations may need to access Mobility binding messages and Return Routability messages for diagnostic, packet accounting and local policy setting purposes. In order to provide portability for Mobile IP applications that use sockets under IPv6, standardization is needed for the Mobile IPv6 specific APIs. This document provides mechanism for API access to retrieve and set information for Mobility Header messages, Home address destination option and Routing header type 2 extension headers. It also discusses the common data structures and defines that might be used by the advanced Mobile IPv6 socket applications.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 38 of 65
IST-2001-34056 Standardisation Report Issue 1.0
QoS
Key Issues None.
Standards Development Title IPv6 Flow Label Specification
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt
Abstract This document specifies the IPv6 Flow Label field, the requirements for IPv6 source nodes labelling flows, the requirements for IPv6 nodes forwarding labelled 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.
Comment Revised.
Title Textual Conventions for IPv6 Flow Label
URL http://www.ietf.org/internet-drafts/draft-ietf-ops-ipv6-flowlabel-00.txt
Abstract This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations.
Comment This is a new draft since the last report. It is in IETF Last Call until 4th May for consideration as a Proposed Standard.
© 6LINK www.6link.org Page 39 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Security
Key Issues
Cryptographically-Generated Addresses IPR Ericsson have stated that they will not assert any patents they hold relating to draft-ietf-send-ipsec-00.txt should any part of that document be included in any SEND (Secure Neighbour Discovery) standard. It is hoped that Microsoft will make a similar statement soon.
Standards Development Title Firewalling Considerations for IPv6
URL http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-01.txt
Abstract 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.
Comment Revised.
Title IPv6 Neighbour Discovery trust models and threats
URL http://www.ietf.org/internet-drafts/draft-ietf-send-psreq-03.txt
Abstract The existing IETF standards specify that IPv6 Neighbor Discovery and Address Autoconfiguration mechanisms may be protected with IPsec AH. However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery.
Comment Revised following WG Last Call. There is an issues register at http://www.tml.hut.fi/~pnr/SEND/issues.html. Will go to the IESG soon.
© 6LINK www.6link.org Page 40 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Security Considerations for 6to4
URL http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-02.txt
Abstract The IPv6 interim mechanism 6to4 (RFC3056) uses automatic IPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes Relay Routers and Routers, which accept and decapsulate IPv4 traffic from anywhere. There aren't many constraints on the embedded IPv6 packets, or where IPv4 traffic will be automatically tunneled to. These could enable one to go around access controls, and more likely, being able to perform proxy Denial of Service attacks using 6to4 relays or routers as reflectors. Anyone is also capable of spoofing traffic from non-6to4 addresses, as if it was coming from a relay, to a 6to4 node. This document discusses these issues in more detail and tries to suggest enhancements to alleviate the problems.
Comment Revised.
Title Access Control Prefix Router Advertisement Option for IPv6
URL http://www.ietf.org/internet-drafts/draft-bellovin-ipv6-accessprefix-01.txt
Abstract Some very low-end devices are expected to rely on address-based authentication, even though that is not a high-security mechanism. In particular, they may wish to permit access by "local" peers only, for some value of "local". This memo proposes a new Router Advertisement option to supply a list of privileged prefixes.
Comment Revised. Further discussion is required. May reduce complexity and combine with Brian Zill’s draft (draft-zill-ipv6wg-zone-prefixlen-00.txt).
Title How to make IPsec more mobile IPv6 friendly
URL http://www.ietf.org/internet-drafts/draft-dupont-ipsec-mipv6-03.txt
Abstract IPsec specifications [1-6] do not work well with any mobility device based on addresses [7]. Mobile IPv6 interaction with IPsec is still far from being well achieved. This is mainly due to bad interpretations of IPsec specifications. HIP (Host Identity Payload) [9] should change this regrettable situation. This document specifies some points where improvements can be made in many current implementations, on the way of making IPsec more suitable for Mobile IPv6.
Comment Revised.
© 6LINK www.6link.org Page 41 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title SEcure Neighbor Discovery (SEND)
URL http://www.ietf.org/internet-drafts/draft-ietf-send-ipsec-00.txt
Abstract IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other nodes on the link, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. If not secured, ND protocol is vulnerable to various attacks. This document specifies an extension to IPsec for securing ND. Contrary to the original ND specifications that also called for use of IPsec, this extension does not require the creation of a large number of manually configured security associations.
Comment This is a new draft since the last report. Open issues require further discussion on the mailing list. A new revision is expected before IETF57 in July. If there are no major technical issues and CGA IPR issues are resolved, will submit to IESG immediately after IETF57.
Title Using IKE with IPv6 Cryptographically Generated Address
URL http://www.ietf.org/internet-drafts/draft-laganier-ike-ipv6-cga-00.txt
Abstract This document describes IKE peer authentication via IPv6 Cryptographically Generated Addresses. These have been proposed to solve several security issues in the absence of any trusted infrastructure.
Comment This is a new draft since the last report.
Title IP Authentication Header
URL http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-03.txt
Abstract This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98b]. Section 7 provides a brief review of the differences between this document and RFC 2402.
Comment Revised.
© 6LINK www.6link.org Page 42 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IP Encapsulating Security Payload (ESP)
URL http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-05.txt
Abstract This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406.
Comment Revised.
Title Securing IPv6 Neighbor Discovery
URL http://www.ietf.org/internet-drafts/draft-montenegro-send-cga-rr-01.txt
Abstract The known security vulnerabilities in Neighbor Discovery have not been properly dealt with. This note suggests some techniques based on cryptographically generated addresses and probes that may be applied even in the absence of a pre-established security relationship between the parties involved.
Comment Revised.
Title Effects of ICMPv6 on IKE
URL http://www.ietf.org/internet-drafts/draft-arkko-icmpv6-ike-effects-02.txt
Abstract The ICMPv6 protocol provides many functions which in IPv4 were either non-existent or provided by lower layers. IPv6 architecture also makes it possible to secure all IP packets using IPsec, even ICMPv6 messages. IPsec architecture has a Security Policy Database that specifies which traffic is protected, and how. It turns out that the specification of policies in the presence of ICMPv6 traffic is hard, particularly with ICMPv6 packets related to Neighbor Discovery. Sound looking policies may easily lead to loops: The establishment of security requires Neighbor Discovery messages which can not be sent since security has not been established yet. The purpose of this draft is to inform system administrators and IPsec implementors in which manner they can handle the ICMPv6 messages. Common understanding of the way that these messages are handled is also necessary for interoperability, in case vendors hardcode such rules in to products.
Comment Revised.
© 6LINK www.6link.org Page 43 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Manual Configuration of Security Associations for IPv6 Neighbor Discovery
URL http://www.ietf.org/internet-drafts/draft-arkko-manual-icmpv6-sas-02.txt
Abstract This informational document discusses the use of manually configured IPsec security associations to protect IPv6 Neighbor Discovery (ND) messages. IPsec security associations are generally identified by the triple (security parameters index, destination address, protocol). In the case of Neighbor Discovery, configuring these associations requires some effort, however. There are multiple known destination addresses plus a number of addresses that depend on the physical link addresses. This document describes the security implications of protecting or not protecting the Neighbor Discovery messages and lists the security associations that must be configured manually. The presented method is applicable only in small networks, but some approaches for reducing the configuration effort are discussed.
Comment Revised.
Title Mobile IP version 6 Route Optimization Security Design Background
URL http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-00.txt
Abstract In this document we present the design rationale behind the Mobile IPv6 (MIPv6) Route Optimization Security Design. The purpose of this document is to assemble together the collective wisdom and understanding obtained during the Mobile IPv6 Security Design in 2001-2002. The main body of the document is intentionally kept relatively short: the details of a number of specific issues are explored in appendices and elsewhere. The document has two target audiences. Firstly, it is intended for MIPv6 implementors so that they could better understand the reasons behind the design choices in MIPv6 security procedures. Secondly, it is aimed to help other people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their design.
Comment This is a new draft since the last report.
Title Authentication/Confidentiality for OSPFv3
URL http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-01.txt
Abstract This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header.
Comment Revised.
© 6LINK www.6link.org Page 44 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Transition
Key Issues
NAT-PT The v6ops Working Group will develop an Applicability Statement for NAT-PT. There was split consensus on whether to move the existing Proposed Standard to Historic, leave it at PS, or to update it. Majority support was for leaving it at PS. There was some comment that 3GPP may modify their current dependence on NAT-PT.
6bone Shutdown The 6bone meeting at IETF56 reached consensus on a phaseout plan for the 6bone network based on cutting-off 6bone address allocations from January 1st 2004 and shutting the network down completely on 6th June 2006.
Standards Development Title Transition Scenarios for ISP Networks
URL http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-05.txt
Abstract This document describes the different types of Internet Service Provider (ISP) networks in existence today. It will provide design and operational considerations in delivering network services to customers for seven specific areas in an effort to better identify specific issues which may arise during a transition to IPv6.
Comment Revised.
Title An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)
URL http://www.ietf.org/internet-drafts/draft-tsuchiya-mtp-01.txt
Abstract In the stage of the transition from IPv4 to IPv6 it is necessary that IPv4 nodes and IPv6 nodes can communicate directly. This memo proposes a mechanism which enables such direct communication for multicast, in addition to that for unicast defined in RFC2765(SIIT) and RFC2766(NAT-PT.)
Comment Revised.
© 6LINK www.6link.org Page 45 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Transition Scenarios for 3GPP Networks
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-03.txt
Abstract This document describes different scenarios in Third Generation Partnership Project (3GPP) defined packet network, i.e. General Packet Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g. in the Internet. GPRS network internal transition scenarios, i.e. between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study.
Comment Revised.
Title 6bone (IPv6 Testing Address Allocation) Phaseout
URL http://www.ietf.org/internet-drafts/draft-fink-6bone-phaseout-01.txt
Abstract The 6bone was established in 1996 by the IETF as an IPv6 Testbed network to enable various IPv6 testing as well as to assist in the transitioning of IPv6 into the Internet. It operates under the IPv6 address allocation 3FFE::/16 from RFC 2471. As IPv6 is beginning its production deployment it is appropriate to plan for the phaseout of the 6bone. This note establishes a plan for a multi-year phaseout of the 6bone and its address allocation on the assumption that the IETF is the appropriate place to determine this. This document is intended to obsolete RFC 2471, "IPv6 Testing Address Allocation", December, 1998. RFC 2471 will become historic.
Comment This is a new draft since the last report. This documents the dates agreed at IETF56 for allocation cut-off on 01/01/04 and shutdown on 06/06/06.
Title Unmanaged Networks IPv6 Transition Scenarios
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unman-scenarios-00.txt
Abstract In order to evaluate the suitability of transition mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged networks", which typically correspond to home networks or small office networks.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 46 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Issues when translating between IPv4 and IPv6
URL http://www.ietf.org/internet-drafts/draft-vanderpol-v6ops-translation-issues-00.txt
Abstract During the transition from IPv4 to IPv6 both protocols will be used simultaneously. Most nodes will support both protocols and will be able to communicate via both IPv4 and IPv6 transport. Problems arise when a node only supports IPv4 and it wants to communicate with a node that only supports IPv6. Translation between the two IP protocols might be needed in some cases. This memo discusses the problems involved in translation between IPv4 and IPv6.
Comment This is a new draft since the last report.
Title A View on IPv6 Transition Architecture
URL http://www.ietf.org/internet-drafts/draft-savola-v6ops-transarch-00.txt
Abstract 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.
Comment This is a new draft since the last report.
Title Integrated transition toolbox for 3gpp cases
URL http://www.ietf.org/internet-drafts/draft-thakur-integrated-transition-toolbox-00.txt
Abstract This document describes the implementation of a transition 'toolbox' which intelligently choses between usage of application proxies, translation and tunneling depending on the deployment scenario. This document does not attempt to solve NA(P)T-PT related issues, though it does deal with certain issues.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 47 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Enterprise Networks Scenarios
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-entnet-scenarios-00.txt
Abstract IPv6 will be deployed in Enterprise networks. This scenario has requirements for the adoption of IPv6. This document will focus upon and define: a set of technology scenarios that shall exist for the enterprise network, the set of transition variables, transition methods, and tools required by different scenarios. The document using these definitions will define the points of transition for an Enterprise network.
Comment This is a new draft since the last report.
Title Delegation of 2.0.0.2.ip6.arpa
URL http://www.ietf.org/internet-drafts/draft-ymbk-6to4-arpa-delegation-00.txt
Abstract This document discusses the need for delegation of the 2.0.0.2.ip6.arpa DNS zone in order to enable reverse lookups for 6to4 addresses.
Comment This is a new draft since the last report. There was not consensus in the Working Group meeting at IETF56 to adopt this as a work item and discussion will continue on the mailing list.
Title Dual stack vs NAT-PT
URL http://www.ietf.org/internet-drafts/draft-durand-v6ops-dualstack-vs-natpt-00.txt
Abstract Outside of the IETF community, lot of people think that IPv4 to IPv6 transition consist merely at solving the problem of how does a v4 box communicate with a v6 box and vice versa. Within the IETF, the dual stack approach has long been defined. There is an ongoing discussion to understand if translation with tools like [NAT-PT] is absolutly needed to enable IPv6 nodes to communicate with an IPv4 node or if we can/should mandate IPv6 nodes to also deploy an IPv4 stack if/when they needs to communicate with IPv4 nodes. This draft is aimed at clarifying the discussion without taking side by studying in 3 cases the implications of mandating a dual-stack versus the implications of deploying a translation device.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 48 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Issues with NAT-PT DNS ALG in RFC2766
URL http://www.ietf.org/internet-drafts/draft-durand-v6ops-natpt-dns-alg-issues-00.txt
Abstract Recent discussions on the need to translate or not between IPv4 and IPv6 have brought a better understanding on the impact of tools like NAT-PT [NAT-PT]. Several problems have been identified around the DNS ALG functionality. An alternative solution that does not require this DNS ALG for connections initiated by the IPv6 side has been proposed. This memo aims at analyzing the pros and cons of both solutions in that case. Connections initiated by the IPv4 side would always require the help of a DNS-ALG and thus are not covered by this memo.
Comment This is a new draft since the last report.
Title Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
URL http://www.ietf.org/internet-drafts/draft-templin-isatap-dhcp-00.txt
Abstract This document specifies a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that provides two lists of configuration data for nodes that implement the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
Comment This is a new draft since the last report.
Title Basic Transition Mechanisms for IPv6 Hosts and Routers
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-00.txt
Abstract This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 2893.
Comment This is a new draft since the last report. Further revision is necessary to address issues raised on mailing list.
© 6LINK www.6link.org Page 49 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Transition Analysis for ISP Networks
URL http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-analysis-00.txt
Abstract This document provides analysis of how to transition the different types of Internet Service Provider (ISP) networks to IPv6. It will provide design recommendations which may be followed to successfully deploy IPv6 services on a network that began as an IPv4 network. This is the companion document to draft-mickles-v6ops-isp-scenarios-04.txt which provides detailed background information on all scenarios.
Comment This is a new draft since the last report.
Title An IPv4 - IPv6 multicast gateway
URL http://www.ietf.org/internet-drafts/draft-venaas-mboned-v4v6mcastgw-00.txt
Abstract 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.
Comment This is a new draft since the last report.
Title IPv6 on by Default
URL http://www.ietf.org/internet-drafts/draft-roy-v6ops-v6onbydefault-00.txt
Abstract The dual stack model is based on the assumption that applications can try communicating to destinations over IPv6 first and fall back to IPv4 if IPv6 doesn't work. Before turning the dual stack on by default, we need to make sure that this assumption holds even in cases where IPv6 connectivity is not perfect. This document looks at scenarios in which things can go wrong if the IPv6 dual stack is enabled by default.
Comment This is a new draft since the last report.
Title Evaluation of Transition Mechanisms for Unmanaged Networks
URL http://www.ietf.org/internet-drafts/draft-huitema-v6ops-unmaneval-00.txt
Abstract In a companion paper we defined the "unmanaged networks" scope, which typically correspond to home networks or small office networks, and the requirements for IPv6 transition mechanism in that scope. We start from this analysis and evaluate here the suitability of mechanisms defined in the NGTRANS working group.
Comment This is a new draft since the last report although is actually a revision to an expired ngtrans draft. Further work required.
© 6LINK www.6link.org Page 50 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Delegation of E.F.F.3.IP6.ARPA
URL http://www.ietf.org/internet-drafts/draft-ymbk-6bone-arpa-delegation-01.txt
Abstract This document discusses the need for delegation of the E.F.F.3.IP6.ARPA DNS zone in order to enable reverse lookups for 6bone addresses, and makes specific recommendations for the process needed to accomplish this.
Comment This is a new draft since the last report. Has completed IETF Last Call for consideration as Best Current Practice.
Title Path MTU Support for IPv6-in-IPv4 Tunnels
URL http://www.ietf.org/internet-drafts/draft-templin-tunnelmtu-00.txt
Abstract This document specifies a means for IPv6-in-IPv4 tunnels to participate in IPv6 path MTU discovery. Also specified is a means for the tunnel decapsulator to inform the encapsulator of appropriate per-neighbor MTU values using IPv6 neighbor discovery.
Comment This is a new draft since the last report.
Title Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-13.txt
Abstract This document specifies an Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 hosts and routers within IPv4 sites. ISATAP treats the site's IPv4 infrastructure as a link layer for IPv6 with no requirement for IPv4 multicast. ISATAP enables intra-site automatic IPv6-in-IPv4 tunneling whether globally assigned or private IPv4 addresses are used.
Comment Revised.
Title SIP Issues in Dual-stack Environments
URL http://www.ietf.org/internet-drafts/draft-persson-sipping-sip-issues-dual-stack-00.txt
Abstract The advent of IPv6 in addition to IPv4 makes hosts and servers dual-stack. SIP communications can be used in both environments but there is little understanding what will happen if some nodes are dual-stack while others, presently the majority, is IPv4 only enabled. This document describes some scenarios and associated issues when dual-stack users and servers try to communicate with IPv4 only hosts using SIP. It is not evident that interoperability is achieved, and if that is not the case, this would severely limit the usability of both SIP and IPv6.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 51 of 65
IST-2001-34056 Standardisation Report Issue 1.0
3GPP
Key Issues There was a 3GPP-IETF Release 6 Workshop held in San Francisco, USA, at the end of January and the major conclusions of that meeting were:
Release 5: 3GPP Rel 5 frozen including items left over from liaison statement. Major fixes will have to wait until Rel 6
Release 6: An updated dependency list includes some Rel 6 dependencies but not all of Rel 6 items are known yet.
Documents relevant to 3GPP RAN3 decisions on IPv6 are RP-010499, RP-010416, RP-010405, TR 25.933
IETF will develop a SIP/SDP/RTP IPv4/IPv6 transition story (see ‘SIP Issues in Dual-stack Environments’ under Transition, above). 3GPP encourages this work. 3GPP needs this for Rel 6 (approx. Dec. 2003)
Standards Development Title Analysis on IPv6 Transition in 3GPP Networks
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-03.txt
Abstract This document analyzes making the transition to IPv6 in Third Generation Partnership Project (3GPP) General Packet Radio Service (GPRS) packet networks. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed.
Comment Revised.
Title 3GPP IETF Dependencies and Priorities
URL http://www.3gpp.org/TB/Other/IETF.htm
Abstract Details the 3GPP dependencies on IETF documents and the associated priorities
Comment Only 2 Release 5 dependencies are outstanding, both related to SIP.
© 6LINK www.6link.org Page 52 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IMEI-based universal IPv6 interface IDs
URL http://www.ietf.org/internet-drafts/draft-dupont-ipv6-imei-02.txt
Abstract The IPv6 addressing architecture [1] defines a modified EUI-64 format for interface identifiers. These interface identifiers may have global scope when a global token is available (e.g., IEEE 802 48-bit MAC or IEEE EUI-64 identifiers). Such a global token, the IMEI (International Mobile station Equipment Identity), is defined for GSM and UMTS terminals [2, 3, 4] and has the same properties than identifiers based on IEEE standards. This document explains the construction of a global IPv6 interface identifier from an IMEI.
Comment Revised.
© 6LINK www.6link.org Page 53 of 65
IST-2001-34056 Standardisation Report Issue 1.0
RIR Developments
Key Issues None.
Policy Development Title IPv6 Address Allocation and Assignment Policy
URL http://www.ripe.net/ripe/docs/ipv6policy.html
Abstract This document defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. This document obsoletes the "Provisional IPv6 assignment and allocation policy document". It was developed through joint discussions among the APNIC, ARIN and RIPE communities. "Assignments for Internet Experiments" has been included in this latest version.
Comment Published 22nd January 2003. Obsoletes ripe-196 and ripe-246.
© 6LINK www.6link.org Page 54 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Miscellaneous
Key Issues None.
Standards Development Title IPv6 Node Requirements
URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-03.txt
Abstract This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
Comment Revised. IETF56 discussions indicate further work is required to improve clarity, e.g. with regard to security requirements and DHCPv6.
Title Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Application Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
© 6LINK www.6link.org Page 55 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-ops-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Operations & Management Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
Title Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-routing-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
Title Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-gen-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF General Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
Title Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF documented standards. This material was originally presented in a single document, but has subsequently been split into 8 documents based on IETF Areas. This document is a general overview of the project.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
© 6LINK www.6link.org Page 56 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-int-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
Title Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-sec-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
Title Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-trans-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
Title Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
URL http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-subip-00.txt
Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards.
Comment This is a new draft since the last report. This draft and the associated drafts also listed here were all broken out of the original IPv4 survey document to better facilitate IETF Area review, comment and input.
© 6LINK www.6link.org Page 57 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title IPv6 Anycast Functionality/Terminology Definition
URL http://www.ietf.org/internet-drafts/draft-doi-ipv6-anycast-func-term-00.txt
Abstract Today, the use of IPv6 anycast is limited. This is because the usage of IPv6 anycast is still unclear. This document describes the usage of IPv6 anycast with some examples. Moreover, we describe the functionalities of anycast, and try to define the terminology of anycast for future discussion.
Comment This is a new draft since the last report.
Title IP Header Compression over PPP
URL http://www.ietf.org/internet-drafts/draft-koren-pppext-rfc2509bis-03.txt
Abstract This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC1332, RFC2023). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC2507, RFC2508 and RFCYYYY.
Comment Revised.
Title Terminology for Benchmarking BGP Device Convergence in the Control Plane
URL http://www.ietf.org/internet-drafts/draft-ietf-bmwg-conterm-04.txt
Abstract This draft establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant.
Comment Revised.
© 6LINK www.6link.org Page 58 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Title The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header
URL http://www.ietf.org/internet-drafts/draft-park-pmtu-ipv6-option-header-00.txt
Abstract This document presents a new method for the PMTU discovery for IPv6. To discover the PMTU of a path, a source node measures its actual PMTU using the newly defined Hop-by-Hop Option header, whereas a source node initially assumes that the PMTU of a path is the known MTU of the first hop in the path in the previous one [1981]. In order to measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet when node is beginning. This can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size). Most of all, since existing PMTU has a weak point for security and denial-of-service attacks, this document suggests a security function when PMTU is going on. All IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification.
Comment This is a new draft since the last report.
Title Procedures for Renumbering an IPv6 Network without a Flag Day
URL http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-00.txt
Abstract This document addresses the key procedural issues in renumbering an IPv6 network. In certain areas, it is necessarily incomplete; it points out those areas, however. It may be considered an update to RFC 2072. It presumes the use of IPv6 Autoconfiguration as described in RFC 2894.
Comment This is a new draft since the last report.
© 6LINK www.6link.org Page 59 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Acronyms IETF Internet Engineering Task Force
IESG Internet Engineering Steering Group
IAB Internet Architecture Board
WG Working Group
3GPP Third Generation Partnership Project
RIR Regional Internet Registry
DNS Domain Name System
ICMP Internet Control Message Protocol
API Application Programming Interface
QoS Quality of Service
FtoH Fibre to the Home
VPN Virtual Private Network
LAN Local Area Network
SOHO Small Office Home Office
DSL Digital Subscriber Line
IM Instant Messaging, IP Multimedia
NAT-PT Network Address Translation - Protocol Translation
ALG Application Layer Gateway
RFC Request for Comments
PS Proposed Standard
DS Draft Standard
STD Standard
I-D Internet Draft
MIB Management Information Base
BOF Birds of a Feather
© 6LINK www.6link.org Page 60 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Appendix Due to the large volume of standards documents relating to IPv6, the lists below are not guaranteed to be exhaustive or absolutely accurate.
New drafts New drafts published since the last Standardisation Report are:
The Impact of Site-Local Addressing in Internet Protocol, Version 6 (IPv6)
Moderate Use Case for IPv6 Site-Local Addresses
IPv6 Global Unicast Address Format
IPv6 Documentation Address
Organization Zone Prefix Length Discovery
Site-Local Requirements
Results from Interoperability Tests of DHCPv6 Implementations
IPv6 Deployment using Device ID
IPv6 Domain Name Auto-Registration (6DNAR)
A Guide to Implementing Stateless DHCPv6 Service
Site Specific Options for DHCP for IPv6
IPv6 Router Advertisement based DNS Autoconfiguration
IPv6 Extensions for DNS Plug and Play
Dynamic reverse DNS for IPv6
Support of address families in OSPFv3
Protocol Topology Support for IS-IS
Dynamic Binding Update Using AAA
Enhanced Forwarding from Previous Care-of Address for Fast Mobile IPv6 Handovers (eFWD)
Network Mobility Support Requirements
Multiple Care-of Address Registration on Mobile IPv6
The Autoconfiguration of Recursive DNS Server and the Optimization of DNS Name Resolution in Hierarchical Mobile IPv6
Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks
IPv4 traversal for MIPv6 based Mobile Routers
Mobile Network Prefix Delegation extension for Mobile IPv6
Context Transfer and Fast Mobile IPv6 Interactions in a Layer-2 Source-Triggered Anticipative Handover
Fast Handover Agent (FHA) for Fast Router Discovery in FMIPv6
© 6LINK www.6link.org Page 61 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Preconfigured Binding Management Keys for Mobile IPv6
Multihoming Using IPv6 Addressing Derived from AS Numbers
Application of the MIPv6 protocol to the multi-homing problem
A road-map for multihoming in IPv6
IPv6 Site Multihoming: Now What?
IPv6 Socket API for source address selection
Textual Conventions for IPv6 Flow Label
SEcure Neighbor Discovery (SEND)
Using IKE with IPv6 Cryptographically Generated Address
Mobile IP version 6 Route Optimization Security Design Background
6bone (IPv6 Testing Address Allocation) Phaseout
Unmanaged Networks IPv6 Transition Scenarios
Issues when translating between IPv4 and IPv6
A View on IPv6 Transition Architecture
Integrated transition toolbox for 3gpp cases
IPv6 Enterprise Networks Scenarios
Delegation of 2.0.0.2.ip6.arpa
Dual stack vs NAT-PT
Issues with NAT-PT DNS ALG in RFC2766
Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Basic Transition Mechanisms for IPv6 Hosts and Routers
Transition Analysis for ISP Networks
An IPv4 - IPv6 multicast gateway
IPv6 on by Default
Evaluation of Transition Mechanisms for Unmanaged Networks
Delegation of E.F.F.3.IP6.ARPA
Path MTU Support for IPv6-in-IPv4 Tunnels
Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards
Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards
Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards
Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards
Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards
© 6LINK www.6link.org Page 62 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards
Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards
Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards
Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards
IPv6 Anycast Functionality/Terminology Definition
SIP Issues in Dual-stack Environments
The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header
Procedures for Renumbering an IPv6 Network without a Flag Day
Revised drafts Existing drafts that have been revised since the last report are:
Terminology for Benchmarking BGP Device Convergence in the Control Plane
IP Header Compression over PPP
IPv6 Node Requirements
IMEI-based universal IPv6 interface IDs
Analysis on IPv6 Transition in 3GPP Networks
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
Transition Scenarios for 3GPP Networks
An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)
Transition Scenarios for ISP Networks
Authentication/Confidentiality for OSPFv3
Manual Configuration of Security Associations for IPv6 Neighbor Discovery
Effects of ICMPv6 on IKE
Securing IPv6 Neighbor Discovery
IP Encapsulating Security Payload (ESP)
IP Authentication Header
How to make IPsec more mobile IPv6 friendly
Access Control Prefix Router Advertisement Option for IPv6
Security Considerations for 6to4
IPv6 Neighbour Discovery trust models and threats
Firewalling Considerations for IPv6
IPv6 Flow Label Specification
Advanced Sockets API for IPv6
Basic Socket Interface Extensions for IPv6
Management Information Base for the Internet Protocol (IP)
© 6LINK www.6link.org Page 63 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Management Information Base for the Transmission Control Protocol (TCP)
Local Key Exchange for Mobile IPv6 Local Binding Security Association
Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA)
Localized Mobility Management Requirements
SIM Authentication over IPv6 (SIM6)
Localized Key Management for AAA in MobileIPv6
Diameter Mobile IPv6 Application
Fast Handovers for Mobile IPv6
Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents
Mobile IPv6 Authentication, Authorization, and Accounting Requirements
Mobility Support in IPv6
IPv6 Fast Router Advertisement
Routing IPv6 with IS-IS
Traffic Engineering Extensions to OSPF version 3
Source-Specific Multicast for IP
Using IGMPv3 and MLDv2 For Source-Specific Multicast
Source Address Selection for Multicast Listener Discovery Protocol (RFC 2710)
Duplicate Address Detection Optimization using IPv6 Multicast Listener Discovery
Considerations for IGMP and MLD snooping switches
IGMPv3/MLDv2 and Multicast Routing Protocol Interaction
Embedding the Address of RP in IPv6 Multicast Address
IP encapsulation and address resolution over InfiniBand networks
A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block
An IPv6 Provider-Independent Global Unicast Address Format
Application and Use of the IPv6 Provider Independent Global Unicast Address Format
Internet Protocol Version 6 (IPv6) Addressing Architecture
RFC 3041 Considered Harmful
IPv6 Router Advertisement DNS Resolver Option
Optimistic Duplicate Address Detection
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Requirements for IPv6 prefix delegation
© 6LINK www.6link.org Page 64 of 65
IST-2001-34056 Standardisation Report Issue 1.0
Performing DNS queries via IP Multicast
Domain Name Auto-Registration for Plugged-in IPv6 Nodes
DNS Configuration options for DHCPv6
IPv6 Prefix Options for DHCPv6
Time Configuration Options for DHCPv6
NIS Configuration Options for DHCPv6
Client Preferred Prefix option for DHCPv6
Linklocal Multicast Name Resolution (LLMNR)
IPv6 DNS transition issues
DNS Extensions to support IP version 6
IP Version 6 over MAPOS
Goals for IPv6 Site-Multihoming Architectures
© 6LINK www.6link.org Page 65 of 65