D5.1.2 - ipv6-es.com · Standardisation of IPv6 technology is now starting to adopt an ‘operations’ perspective, as evidenced by the re-chartering of the DNS Operations Working

© 6LINK

IST-2001-34056

Deliverable D5.1.2

"Standardisation Report"

Contractual date of delivery to the European Commission:

August 2002

Actual date of delivery to the European Commission

August 2002

Editor(s) M. Ford (BT)

Participant(s) BT, Consulintel

Workpackage WP5

Title of Deliverable Standardisation Report

Security Pub

Deliverable Type R

Version Issue 1

Number of pages 49 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

IST-2001-34056 Standardisation Report Issue 1

© 6LINK www.6link.org Page 2 of 2

Table of Contents Table of Contents ..........................................................................................................................2 Overview .........................................................................................................................................3 People & Process ...........................................................................................................................4 Addressing.......................................................................................................................................5 Autoconfiguration..........................................................................................................................9 DNS ...............................................................................................................................................13 IPv6 over Link Layers .................................................................................................................16 Multicast ........................................................................................................................................17 ICMP .............................................................................................................................................19 Mobility..........................................................................................................................................20 Multihoming .................................................................................................................................25 Network Management.................................................................................................................26 API .................................................................................................................................................28 QoS ................................................................................................................................................30 Security ..........................................................................................................................................31 Transition ......................................................................................................................................35 3GPP..............................................................................................................................................42 RIR Policy .....................................................................................................................................44 Miscellaneous................................................................................................................................46 Acronyms ......................................................................................................................................49 Please address comments and/or queries related to this document to the author, Mat Ford ([email protected]).



Overview This report attempts to capture the status of IPv6 technology standardisation in August 2002. It is primarily based on the proceedings of the 54th 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. Recent technical highlights include:

• Rough consensus to do Duplicate Address Detection (DAD) not Duplicate Interface Identifier Detection (DIID)

• Removal of reserved bits in site-local subnet ID field • Work will continue on DHCP and DHCP-less solutions to DNS discovery • DHCPv6 and Proxy RAs are the focus for prefix delegation work • Lots of interest in forming a WG to work on making anycast useful for services

and applications Standardisation of IPv6 technology is now starting to adopt an ‘operations’ perspective, as evidenced by the re-chartering of the DNS Operations Working Group to focus on IPv6 DNS operational issues, the closure of the Next Generation Transition Working Group to be replaced by the IPv6 Operations Working Group, and the presence of an IPv6 Implementation and Deployment Experiences Panel at the IESG Plenary meeting during IETF54. The IPv6 Working Group has categorised its work to aid future progress and the ‘Urgent for Deployment’ category includes:

• Prefix delegation • DNS discovery • MIBs

Priorities for the IETF, but not necessarily the IPv6 Working Group, include: • Secure, robust plug and play • Routing protocol updates • Anycast architecture

The IPv6 Implementation and Deployment Experiences Panel, held during the IESG Plenary meeting at IETF54, identified the most pressing needs for IPv6 deployment as:

• Prefix delegation • DNS/Other server discovery • IPv6 transport root/ccTLD/gTLD DNS servers • IPv6 PIM support • MLD-snooping L2 switches • Stabilised dual-stack routers • Educational materials • Integrated MIBs • Move to bandwidth-based billing

Where these requirements are standards-related, they are being addressed by some of the documents identified below.



People & Process The Next Generation Working Group (ngtrans) is to be wound up and a new IPv6 Operations Working Group (v6ops) will pick up some of the ngtrans work. The chairs of v6ops will be Margaret Wasserman (WindRiver Systems) and Jun Ichiro ‘itojun’ Hagino (IIJ). IPv6 is now viewed as an operational protocol within the IETF and it is felt that the work of ngtrans is complete. From the draft v6ops charter, “The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides guidance for network operators on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.” V6ops will be holding an interim meeting in Sunnyvale, California, USA, on Sept 18-19. Further information about the meeting is available from http://home.attbi.com/~margaretw/v6ops-Interim-Sep02.html The DNS Operations Working Group (dnsops) is to be re-chartered to focus on IPv6 DNS issues, again emphasising the operational phase that IPv6 technology deployment is now entering.



Addressing

Key Issues Discussion on whether to remove site-local addresses from the architecture or not concluded with consensus not to remove them, although almost nobody is using them or has implemented them. Rough consensus exists to expand the site-local subnet ID field to include the current ‘0’ field, making the subnet ID a 54-bit field. This would allow sites that have prefixes larger than /48 to re-use their existing subnet IDs. Consensus exists to keep the 64-bit Interface ID field, and to keep the semantics of the ‘u’ bit, although global uniqueness properties cannot actually be guaranteed by any known mechanism. The rough consensus to standardise on Duplicate Address Detection (DAD) as opposed to Duplicate Interface ID Detection (DIID) means changes to some documents are required (e.g. the address architecture document), but not to most implementations, which already do DAD.

Standards Development Title An IPv6 Aggregatable Global Unicast Address Format

URL http://www.ietf.org/rfc/rfc2374.txt

Abstract This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing Architecture" [ARCH]. It is designed to facilitate scalable Internet routing.

Comment Will require updates upon conclusion of addressing architecture issues (see below).

Title IP Version 6 Addressing Architecture

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-09.txt

Abstract This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. 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.

Comment In IESG for publication as Draft Standard. This revision (-09) includes changes to relax the interface identifier uniqueness requirements (from the link to subnet prefix) and to change the definition of Site-Local addresses to make the subnet field 54-bits (and eliminate the 38-bit zero field).



Title RFC2526 Reserved IPv6 Subnet Anycast Address

URL ftp://ftp.isi.edu/in-notes/rfc2526.txt

Abstract The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.

Comment Ready to advance to Draft Standard status, although it is unclear whether implementation should or can be documented.

Title Default Address Selection for IPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-default-addr-select-09.txt

Abstract This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.

Comment New draft available with updates based on IESG and WG feedback. Approved by IESG for publication as Proposed Standard.

Title An analysis of IPv6 anycast

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt

Abstract The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification.

Comment Additional Last Call may be required.



Title IMEI-based universal IPv6 interface IDs

URL http://www.ietf.org/internet-drafts/draft-dupont-ipv6-imei-01.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 Document has been revised although there is still no support for this draft. Title IPv6 Scoped Address Architecture

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-04.txt

Abstract This document specifies the architectural characteristics, expected behaviour, textual representation, and usage of IPv6 addresses of different scopes.

Comment There are issues with this document and the way current routing protocols are specified. Further work is required to understand the problems and possible resolutions.

Title Use of /127 Prefix Length Between Routers Considered Harmful

URL http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-04.txt

Abstract In some cases, the operational decision may be to use IPv6 /127 prefix lengths, especially on point-to-point links between routers. Under certain situations, this may lead to one router claiming both addresses due to subnet-router anycast being implemented. This draft discusses the issue and offers a couple of solutions to the problem; nevertheless, /127 should be avoided between two routers.

Comment This document has generated a lot of discussion on the worth of standardising a maximum /64 prefix length when operators are ignoring it in practice. There are also further implications for the semantics of the ‘u’ and ‘g’ bits, and whether these bits are worth keeping. The current mood of the community seems to be not to change the address architecture. It is not clear what this means for the progress of this document to publication as an Informational RFC.



Title RFC3041 Considered Harmful

URL http://www.ietf.org/internet-drafts/draft-dupont-ipv6-rfc3041harmful-01.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



Autoconfiguration

Key Issues

DNS Discovery There is no consensus yet to support any non-DHCP solution, although work will continue on both DHCP and non-DHCP options.

Prefix Delegation A draft requirements document has been produced. There is still no consensus on which solution to focus on, although RA Proxy and DHCPv6 are the leading candidates. There is still strong support for other solutions as well. Deployment is proceeding in Japan using DHCPv6.

Standards Development Title Default Router Preferences, More-Specific Routes, and Load Sharing

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt

Abstract This document describes two changes to Neighbor Discovery. The first change is an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. The second change is a mandatory modification of the conceptual sending algorithm to support load-sharing among equivalent routers.

Comment WG Last Call has been completed. Submitted to IESG for publication as Proposed Standard.

Title IPv6 Stateless DNS Discovery

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-05.txt

Abstract This documents specifies a method for nodes to find a DNS resolver with minimum configuration in the network and without running a discovery protocol on the nodes.

Comment This mechanism is only for scenarios where there isn't a DHCP server. Needs more discussion.



Title Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)

URL http://www.ietf.org/internet-drafts/draft-haberman-ipngwg-auto-prefix-02.txt

Abstract This document describes a mechanism for the automated delegation of an IPv6 network prefix. It allows routers to request a specific size prefix and inform the upstream router of the routing protocols of which it is capable. Upon authorizing the request the delegating router then returns a prefix, the desired routing protocol, and a lifetime for the use of the prefix.

Comment Title IPv6 Prefix Options for DHCPv6

URL http://www.ietf.org/internet-drafts/draft-troan-dhcpv6-opt-prefix-delegation-01.txt

Abstract The Prefix Delegation option and the Prefix Request option provide a mechanism for delegation of IPv6 prefixes using DHCP. Conceptually, IPv6 prefixes are assigned with these options in the same manner as IPv6 addresses. This prefix delegation mechanism is intended for simple prefix delegation 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 Lots of comments received. Further revisions required. Title Load Balancing for DHCPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt

Abstract This document specifies a load balancing algorithm for use with DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers to decide which one should service a client, without exchanging any information beyond initial configuration. It expands on RFC 3074 "DHC Load Balancing Algorithm" to include DHCPv6.

Comment This document has been combined with the Router Preferences work in http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-02.txt



Title Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-26.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 Draft-27 is in preparation. This revision will provide editorial clarifications and updates to the authentication mechanism.

Title Requirements for IPv6 prefix delegation

URL http://www.ietf.org/internet-drafts/draft-miyakawa-ipv6-prefix-delegation-requirement-00.txt

Abstract This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber’s network (or "site").

Comment Adopted by IPv6 Working Group as a work item. Title Name resolution in zeroconf environment using ICMPv6 node information

query

URL http://www.ietf.org/internet-drafts/draft-itojun-ipv6-nodeinfo-zeroconflookup-00.txt

Abstract The document proposes a way to resolve DNS names in zeroconf environment [Williams, 2002] , by using ICMPv6 node information query/reply [Crawford, 2002] . The proposed protocol works only with IPv6 (not with IPv4).

Comment This is a new personal submission. Title Client Preferred Prefix option for DHCPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.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 This is a new personal submission.



Title PPP IPv6 Control Protocol Extensions for DNS Server Addresses

URL http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-00.txt

Abstract The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document extends the NCP for establishing and configuring Version 6 of the Internet Protocol (IPV6) over PPP, defining the negotiation of primary and secondary Domain Name System (DNS) server IPV6 addresses.




DNS

Key Issues

A6 and Bit label RFCs 2673 and 2874 have been reclassified from Proposed Standard to Experimental.

IPv6 Reverse DNS Several issues exist regarding reverse DNS for IPv6. These include whether to use wildcard PTR records to guarantee responses to queries regardless of the IID, what to do about reverse DNS for privacy addresses, 6to4 addresses and site-scoped addresses.

Standards Development Title Representing IPv6 Addresses in DNS

URL http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-02.txt

Abstract This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status.

Comment Approved by IESG for publication as an Informational RFC. Title Domain Name Auto-Registration for Plugged-in IPv6 Nodes

URL http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-02.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 Will require further revisions. There is an implementation. Goal is Informational RFC.

Title Linklocal Multicast Name Resolution (LLMNR)

URL http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-11.txt

Abstract Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a 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



Title RFC1886 DNS Extensions to support IP version 6


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 new resource record type to store an IPv6 address, a new 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.

Comment Requires inclusion of updates from RFC 3152 ‘Delegation of IP6.ARPA’ before advancement to Draft Standard.

Title Use of ICMPv6 node information query for reverse DNS lookup

URL http://www.ietf.org/internet-drafts/draft-itojun-ipv6-nodeinfo-revlookup-00.txt

Abstract The document proposes an alternative way to perform reverse DNS lookup, by using ICMPv6 node information query/reply [Crawford, 2002] . The proposed protocol works only with IPv6 (not with IPv4).

Comment This is a new personal submission. Title IPv6 DNS transition issues

URL http://www.ietf.org/internet-drafts/draft-durand-ngtrans-dns-issues-00.txt

Abstract This memo summarizes DNS related issues when transitioning a network to IPv6. Those issues have been discussed in the NGtrans, IPv6, DNSext and DNSop working group. Wherever consensus has been reached, it is presented. When consensus has not yet been reached, a list of open issues is presented.

Comment This is a new personal submission. Title Well known site local unicast addresses for DNS resolver

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-05.txt

Abstract This documents specifies a method for nodes to find a DNS resolver with minimum configuration in the network and without running a discovery protocol on the nodes.

Comment



Title Tradeoffs in DNS support for IPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt

Abstract The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on.

Comment Approved by IESG for publication as an Informational RFC. Published as RFC3364 ftp://ftp.rfc-editor.org/in-notes/rfc3364.txt.

Title The ADDR DNS Query-Type

URL http://www.ietf.org/internet-drafts/draft-hall-qtype-addr-00.txt

Abstract This document defines a DNS query-type for "all IP address resource records," specifically including any A and AAAA resource records which may be bound to the queried domain name. This query- type would allow IPv6-aware applications to issue a single query and determine the capabilities of the remote host, rather than having to issue a second query for A resource records in those cases where no AAAA resource records are available.




IPv6 over Link Layers

Key Issues None.

Standards Development Title RFC2464 Transmission of IPv6 Packets over Ethernet Networks


Abstract This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet.

Comment Ready for advancement to Draft Standard. Waiting for completion of implementation checklists.

Title RFC2467 Transmission of IPv6 Packets over FDDI Networks


Abstract This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network.

Comment Ready for advancement to Draft Standard. Waiting for completion of implementation checklists.



Multicast

Key Issues Implementation of PIM for IPv6 and development of MLD-snooping L2 switches have been identified as priorities for IPv6 deployment going forward.

Standards Development Title RFC2710 Multicast Listener Discovery (MLD) for IPv6


Abstract This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.

Comment Will stay at Proposed Standard, awaiting update (MLDv2) from MAGMA Working Group.

Title Link Scoped IPv6 Multicast Addresses

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-link-scoped-mcast-01.txt

Abstract This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for the use of interface-IDs to allocate multicast addresses. When the link-local unicast address is configured at each interface of a host, an interface ID is uniquely determined. By delegating multicast addresses at the same time as the interface ID, each host can identify their multicast addresses automatically at Layer 1 without running an intra- or inter-domain allocation protocol in serverless environments.

Comment In Working Group Last Call for advancement to Proposed Standard. Title Multicast Listener Discovery Version 2 (MLdv2) for IPv6

URL http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt

Abstract This document specifies Version 2 of the Multicast Listener Discovery protocol, MLDv2. MLD is the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighbouring nodes.

Comment



Title Support for Multicast over 6to4 Networks

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-multicast-01.txt

Abstract 6to4 Tunneling allows isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration. This document defines support for IPv6 Multicast over 6to4 networks.

Comment Title IGMP and MLD snooping switches

URL http://www.ietf.org/internet-drafts/draft-ietf-magma-snoop-02.txt

Abstract This memo describes the requirements for IGMP and MLD snooping switches. The requirements for IGMPv2 snooping switches are based on best current practices. IGMPv3 and MLDv2 snooping are also covered in this draft although we are not aware of any such implementations at the time of writing. Areas which are of relevance to IGMP and MLD snooping switches, such as link layer topology changes and Ethernet specific encapsulation issues are also considered.

Comment Title Explicit Multicast (Xcast) Basic Specification

URL http://www.ietf.org/internet-drafts/draft-ooms-xcast-basic-spec-03.txt

Abstract Multicast has become increasingly important with the emergence of network-based applications such as IP telephony and video conferencing. The Internet community has done a significant amount of work on IP multicast over the last decade [1075, 2201, 2236, DEER, DEE2, FARI, HOLB, MBONE, PERL]. However, while traditional multicast schemes are scalable in the sense that they can support very large multicast groups, there are scalability issues when a network needs to support a very large number of distinct multicast groups. This document describes a new scheme for multicast - named Explicit Multicast (Xcast) - that complements the existing schemes. Whereas the existing schemes can support a limited number of very large multicast sessions, Xcast can support a very large number of small multicast sessions. This is achieved by explicitly encoding the list of destinations in the data packets, instead of using a multicast address. The co-operation of Xcast - a data plane mechanism - with existing control planes is described and scenarios for gradual deployment are investigated. Encodings for both IPv4 and IPv6 are proposed.

Comment See www.alcatel.com/xcast for related work.



ICMP

Key Issues None.

Standards Development Title Internet Control Message Protocol (ICMPv6) for the Internet Protocol

Version 6 (IPv6) Specification

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-02.txt

Abstract This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6).

Comment In IESG for publication as Proposed Standard.



Mobility

Key Issues

MobileIPv6 The MobileIPv6 draft still has open issues and it seems likely that further revisions to the draft will be required. The issues register is detailed below.

Fast Handovers The Fast Handovers for MIPv6 work is focussing on an 802.11 specific solution in an effort to determine whether L2-specifiic solutions are required or not.

Standards Development Title Global Connectivity for IPv6 Mobile Ad Hoc Networks

URL http://www.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-01.txt

Abstract This document describes how to provide Internet connectivity with mobile ad-hoc networks. It describes how to obtain a globally routable address , Manet node operation, and Internet-gateway operation. Once a Manet node obtains a global address from an Internet-gateway, it can start to send data to the Internet. Data goes through the Internet-gateway with a routing header specifying the gateway. This connectivity method is not dependent on a particular Manet protocol. Further, use of global connectivity with Mobile IPv6 is specified.

Comment Title Mobility Support in IPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-18.txt

Abstract This document specifies the operation 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, MUST support communications with mobile nodes.

Comment See link to MobileIPv6 Issue Register below for details of outstanding technical issues.



Title Mobility IPv6 handoff by Explicit Multicast

URL http://www.ietf.org/internet-drafts/draft-ezaki-smoothhandoff-xcast6-00.txt

Abstract A handover process on Mobile IPv6 requires a time period referred as handoff latency. This latency is not acceptable to support real-time application. We propose a new smooth handoff method using the Explicit Multicast (xcast) technique. On the wired section, control/user packets are multicasted by Xcast scheme to the Base Stations where Mobile Node (MN) can receive, and then packets are passed to the air-link activated between a BS and the MN. This procedure provides mobility in heterogeneous media environment because this handoff mechanism is basically able to implemented without additional control or intelligence of neither intermediate routers.

Comment This is a new personal submission. Title Selection of MIPv6 Security Level Using a Hashed Address

URL http://www.ietf.org/internet-drafts/draft-arkko-mipv6-select-hash-00.txt

Abstract MIPv6 is being defined with a security solution called Return Routability (RR) that does not need any authentication infrastructure. Given that the solution is "infrastructureless" in this manner, it isn't very easy to control the solution once it is widely deployed. In particular, it isn't clear how the solution could be changed to a new solution, should that ever become necessary. Peers should be able to agree about the use the new solution in a secure manner, without Man-in-the-Middle attackers from being able to mount a Bidding Down attack and downgrade the security back to the original solution. This draft specifies a simple but secure scheme which allows nodes to choose what security solution they use. One currently known drawback of this scheme is that it is based on a technology that has IPR considerations.

Comment This is a new personal submission. Title Mobile IPv6 VPN using Gateway Home Agent

URL http://www.ietf.org/internet-drafts/draft-ohnishi-mobileip-v6vpngateway-00.txt

Abstract Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. It can also be used for public mobility services. One of the most important services is the VPN service enabling users to access their Intranets from outside. Mobile IP does not work well with VPN, however, and this issue is being discussed in the Mobile IP WG [VPN problem]. This document proposes a simple mechanism that combines VPN and Mobile IP functions. This mechanism uses a hierarchical HA architecture and includes an HA with GW functions, called a Gateway Home Agent (GHA).




Title An interconnection mechanism of Mobile IPv4 and Mobile IPv6 using 6to4

URL http://www.ietf.org/internet-drafts/draft-kahng-ngtrans-moving6to4-00.txt

Abstract This document specifies a new mechanism using 6to4 to solve mobility problems in IPv4 and IPv6 interconnected networks. This draft is based on the Architecture of Hierarchical Dual Stack Mobility Agent(HDSMA) that supports the IP version-independent mobility of mobile node and improves the registration efficiency and the performance[3]. The aim is to support 6to4 mechanism for IPv6 transition while mobile node only uses mobile IPv6 capability for mobility services.

Comment This is a new personal submission. Title Route Optimization Support for Localized Mobility Management Based on

IPv6

URL http://www.ietf.org/internet-drafts/draft-han-mobileip-rolmmv6-00.txt

Abstract Using localized mobility management based on IPv6, all packets destined to a mobile node are routed through the local mobility agent in the mobile node's local mobility domain, which then tunnels the packets to the mobile node's current location. Such packet routing mechanism is similar to the triangle routing in Mobile IPv4, which may leave the local mobility agent overloaded and take a longer route thus increasing the network traffic in the local mobility domain. This document specifies a route optimization scheme for localized mobility management based on IPv6 with the help of L2 trigger. Using this, correspondent nodes can cache LCoA of a mobile node if it is actively communicating with the mobile node, and then send their packets for the mobile node directly to the LCoA, bypassing the local mobility agent. This route optimization scheme will result in more efficient localized mobility management. It alleviates the local mobility agent's loads and takes the nearly same handoff delay time as the one in localized mobility management based on IPv6.




Title Connecting Mobile IPv6 Nodes Across IPv4 Clouds Back To IPv6 Domains With Mobile IPv4

URL http://www.ietf.org/internet-drafts/draft-liu-mobileip-mipv6tomipv4-00.txt

Abstract This document specifies a mechanism for Mobile IPv6 nodes of IPv6 Site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. The mechanism is based on Mobile IPv6 and Mobile IPv4 glued together by IPv4 encapsulation for delivering IPv6 packets between the Mobile IPv6 nodes and their Mobile IPv6 home agents. To support the mechanism specified in this draft, the Mobile IPv6 nodes MUST be Mobile IPv4 capable and MUST NOT utilize Mobile IPv6 route optimization when in IPv4 domain, and some of the border routers of the site MUST be capable to act as Mobile IPv4 home agent(s). The IPv6 site does not need to run 6to4 protocol, however.

Comment This is a new personal submission. Title Simultaneous Bindings for Mobile IPv6 Fast Handoffs

URL http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-02.txt

Abstract Fast Handover for Mobile IPv6 [1] and Bidirectional Edge Tunnel Handover [1] describe protocols to minimise the amount of service disruption when performing layer-3 handoffs. This draft extends the Fast Handover protocol with a simultaneous bindings function and the BETH capabilities with a bicasting function to minimise packet loss at the MN. Traffic for the MN is therefore bicast or n-cast for a short period to its current location and to one or more locations where the MN is expected to move to shortly. This removes the timing ambiguity regarding when to start sending traffic for the MN to its new point of attachment following a Fast Handover and allows the decoupling of layer-2 and layer-3 handoffs. It also saves the MN periods of service disruption in the case of ping-pong movement.

Comment Title Hierarchical MIPv6 mobility management (HMIPv6)

URL http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-06.txt

Abstract This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a Hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well suited to implement access control and handoffs between different access technologies.

Comment



Title IPv6 Fast Router Advertisement

URL http://www.ietf.org/internet-drafts/draft-mkhalil-ipv6-fastra-01.txt

Abstract This document specifies an amendment to the router solicitation handling procedures in RFC 2461 that allow for improved default router acquisition performance when an active IP host moves from one subnet to another.

Comment Title Mobility Extensions to RSVP in an RSVP-MobileIPv6 Framework

URL http://www.ietf.org/internet-drafts/draft-shen-nsis-rsvp-mobileipv6-00.txt

Abstract This memo first gives a brief review of a RSVP and Mobile IPv6 interoperation framework proposed in [1] and compared its features with the Performance Requirements set forth by Requirements of a QoS Solution for Mobile IP [2]. The subsequent part of the memo presents specification details including message formats, processing rules and algorithms that form the framework. The vast majority of these specifications have been verified by a prototype implementation. It is expected that this work could serve as a useful input in dealing with NSIS protocol and mobility issue.

Comment 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



Multihoming

Key Issues A schism in the multi6 WG of the IETF has resulted in most of the activity taking place elsewhere. There was no multi6 meeting at IETF54. For more information see the ipv6mh website http://arneill-py.sacramento.ca.us/ipv6mh

Standards Development Title Host-Centric IPv6 Multihoming

URL http://www.ietf.org/internet-drafts/draft-huitema-multi6-hosts-01.txt

Abstract A way to solve the issue of site multihoming is to have a separate site prefix for each connection of the site, and to derive as many addresses for each hosts. This approach to multi-homing, which we call Host-Centric IPv6 Multihoming, has the advantage of minimal impact on the inter-domain routing fabric, since each site prefix can be aggregated within the larger prefix of a specific provider; however, it opens a number of issues, which we will discuss in this memo, including the problem created by the interaction between ingress filtering and multihoming, which we analyze in detail. We then propose a set of specific solutions that enable host centric multihoming, and we review how these solutions meet the requirements of IPv6 site multihoming.

Comment Title Requirements for IPv6 Site-Multihoming Architectures

URL http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-03.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. Existing IPv4 site-multihoming practices, described in a companion draft [1], provides a set of capabilities that must be accommodated by the adopted site-multihoming architecture in IPv6, and a set of limitations that must be overcome, relating in particular to scalability.

Comment



Network Management

Key Issues It is expected that the TCP, UDP and IP Forwarding Table MIBs will have completed WG Last Call by IETF55 in November. The IP MIB has a few outstanding issues and should be ready for WG Last Call by IETF55.

Standards Development Title Management Information Base for the Transmission Control Protocol

(TCP)

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-00.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) in an IP version independent manner.

Comment URL updated to reflect new WG name. Title IP Forwarding Table MIB


Abstract This document 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 related to the forwarding of Internet Protocol (IP) packets, in an IP version independent manner.

Comment URL updated to reflect new WG name. Minor editorial changes only since rev-00.

Title Management Information Base for the Internet Protocol (IP)


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.

Comment URL updated to reflect new WG name.



Title Management Information Base for the User Datagram Protocol (UDP)


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 User Datagram Protocol (UDP) in an IP version independent manner.

Comment URL updated to reflect new WG name. Title IPv6 Node Information Queries

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-09.txt

Abstract This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.

Comment Title Unidentified issues in IPv6 deployment/operation

URL http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-00.txt

Abstract This document tries to identify issues in IPv6 deployment/operation, that are yet to be addressed. The document covers broad range of problems, and therefore, may capture problems that should be discussed in multiple IETF working groups.




API

Key Issues Scoped-address support has been removed from the Basic API document to facilitate publication of the Basic API as an Informational RFC.

Standards Development Title Basic Socket Interface Extensions for IPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-06.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.

Comment In IESG for publication as an Informational RFC. Text related to scoped-address support has been removed and relocated to a separate document (see below) to resolve issues with normative references.

Title Advanced Sockets API for IPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-07.txt

Abstract A separate specification [RFC-2553] contains changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. But another class of applications exists that will also be run under IPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.

Comment In IESG for publication as an Informational RFC.



Title Scoped Address Extensions to the IPv6 Basic Socket API

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scope-api-00.txt

Abstract This document specifies a set of extensions to the basic IPv6 sockets API for the support of scoped addresses.

Comment Relocated here from RFC2553bis (see above) to resolve normative reference issues. This document will only be considered for publication once the Scoped Addressing Architecture document is ready for publication.



QoS

Key Issues Reaching consensus regarding the IPv6 flow label specification has been a slow process, but the current document is progressing. There are not, at present, any QoS mechanisms to make use of this specification. The Next Steps in Signalling WG (nsis) are analysing the fit of the IPv6 Flow Label specification with their requirements.

Standards Development Title IPv6 Flow Label Specification

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-02.txt

Abstract This document specifies the usage of the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, and the requirements for flow state establishment methods.

Comment Another revision is required before WG Last Call. Title The Features of IPv6 Signaling

URL http://www.ietf.org/internet-drafts/draft-choi-ipv6-signaling-02.txt

Abstract In this draft, we describe the features and requirements of IPv6 signaling protocol and explain the needs of QoS signaling in IPv6 network. We also explain mapping of IPv6 signaling with IPv4 in some detail.

Comment



Security

Key Issues

Secure Neighbour Discovery A Secure Neighbour Discovery (send) BOF meeting was held at IETF54 and there was a lot of interest in working on this problem. There was disagreement about whether work should focus on Neighbour Discovery specifically, or should tackle the more general key management problem. Relevant draft documents are detailed below.

Standards Development Title Effects of ICMPv6 on IKE and IPsec Policies

URL http://www.ietf.org/internet-drafts/draft-arkko-icmpv6-ike-effects-01.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. Sound looking policies may easily lead to loops: The establishment of security requires ICMPv6 messages which can't be sent since security hasn't 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 Title Manual SA Configuration for IPv6 Link Local Messages

URL http://www.ietf.org/internet-drafts/draft-arkko-manual-icmpv6-sas-01.txt

Abstract This draft discusses the use of manually configured IPsec SAs to protect ICMPv6 messages such as router discovery and address resolution on the local link. IPsec SAs are generally identified by the triple <SPI, destination address, protocol>. For the ICMPv6 messages configuring the SAs requires some effort, however, since there are multiple known destination addresses plus a number of addresses that depend on the physical link addresses. This draft describes the security implications of protecting or not protecting the link local ICMPv6 messages, lists the SAs that must be configured manually, and discusses some approaches for reducing configuration effort.

Comment



Title Securing IPv6 Neighbour Discovery Using Address Based Keys (ABKs)

URL http://www.ietf.org/internet-drafts/draft-kempf-secure-nd-01.txt

Abstract When an IPv6 node receives a Router Advertisement, how does it know that the node which sent the advertisement is authorized to announce that it routes the prefix? When an IPv6 node receives a Neighbor Advertisement message, how does it know that the node sending the message is, in fact, authorized to claim the binding? The answer is, in the absence of a preconfigured IPsec security association among the nodes on the link and the routers, they don't. In this draft, a lightweight protocol is described for securing the signaling involved in IPv6 Neighbor Discovery. The protocol allows a node receiving a Router Advertisement or a Neighbor Advertisement to have the confidence that the message was authorized by the legitimate owner of the address or prefix being advertised without requiring a preconfigured IPsec security association. A certain degree of infrastructural support is required, but not any more than is currently common for public access IP networks. The protocol is based on some results in identity based cryptosystems that allow a publicly known identifier to function as a public key.

Comment Title Threat Analysis for IPv6 Public Multi-Access Links

URL http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-02.txt

Abstract The Mobile IP Working Group has been conducting a threat analysis for the purpose of securing specific Mobile IPv6 mechanisms. In the process of conducting the analysis, threats were identified that are not specific to Mobile IP but that are amplified by the nature of mobility. These threats are likely to be more or less of an issue within any Public Multi-Access network, regardless of whether mobility is involved. This document discusses threats associated with Public Multi-Access links in IPv6. The document covers non-Mobile IP specific threats uncovered by the Mobile IPv6 study, threats raised in the IPv6 Neighbor Discovery and Stateless Address Autoconfiguration RFCs that have yet to be adequately addressed, and new threats that have not previously been identified.

Comment



Title How to make IPsec more MobileIPv6 friendly

URL http://www.ietf.org/internet-drafts/draft-dupont-ipsec-mipv6-01.txt

Abstract IPsec specifications [1-6] does not work well with Mobile IPv6 [7] and with any mobility device based on addresses [8] even if HIP [9] should change this regrettable situation. But many problems come directly from bad or dubious interpretations of IPsec specifications, so this document presents many points where many current implementations can be improved (i.e., can become more Mobile IPv6 friendly).

Comment Title SIM Authentication EAP extension over AAAv6 (SIM6)

URL http://www.ietf.org/internet-drafts/draft-kniveton-sim6-01.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 Title Securing Group Management in IPv6 with Cryptographically Generated

Addresses

URL http://www.ietf.org/internet-drafts/draft-irtf-gsec-sgmv6-01.txt

Abstract Currently, group membership management in IP Multicast and Anycast can be abused in order to launch denial-of-service (DoS) attacks. The root of the problem is that routers cannot determine if a given host is authorized to join a group (sometimes referred to as the "Proof-of-Membership Problem" [ECUMN00]). We propose a solution for IPv6 based on Group Cryptographically Generated Addresses (G-CGA). These addresses have characteristics of statistical uniqueness and cryptographic verifiability that lend themselves to severely limiting certain classes of DoS attacks. Our scheme is fully distributed and does not require any trusted third party or pre-established security association between the routers and the hosts. This is not only a huge gain in terms of scalability, reliability and overhead, but also in terms of privacy.

Comment



Title Securing IPv6 Neighbour Discovery

URL http://www.ietf.org/internet-drafts/draft-montenegro-send-cga-rr-00.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 This is a new personal submission. Title Trust Models for Secure IPv6 Neighbour Discovery

URL http://www.ietf.org/internet-drafts/draft-nikander-send-trust-models-00.txt

Abstract This document outlines three different trust models for Secure IPv6 Neighbor Discovery (SEND). The trust models correspond to a trusted company intranet, a public network with a trusted service provider, and a public network without any trusted parties.

Comment This is a new personal submission. Title Securing IPv6 Neighbour Discovery Using Cryptographically Generated

Addresses (CGAs)

URL http://www.ietf.org/internet-drafts/draft-arkko-send-cga-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. The original ND specifications called for the use of IPsec for protecting the ND messages. However, in this particular application the use of IPsec may not always be feasible, mainly due to difficulties in key management. If not secured, ND protocol is vulnerable to various attacks. This document specifies a lightweight security solution for ND that does not rely on pre-configuration or trusted third parties. The presented solution uses Cryptographically Generated Addresses.

Comment This is a new personal submission. Cryptographically Generated Addresses are the subject of competing IPR claims from Ericsson and Microsoft.



Transition

Key Issues The Next Generation Transition (ngtrans) Working Group will be closed down very soon. Outstanding work on transition tool development, etc., may move to the new IPv6 Operations (v6ops) Working Group. The developing documents detailing scenarios and solutions for the various transition scenarios (i.e. unmanaged scope networks, ISP networks, enterprise networks, and 3GPP networks) will be progressed in v6ops.

Standards Development Title Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-04.txt

Abstract This document specifies the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) that connects IPv6 hosts and routers (nodes) within IPv4 sites. ISATAP is a transition mechanism that enables incremental deployment of IPv6 by treating the site's IPv4 infrastructure as a Non-Broadcast Multiple Access (NBMA) link layer. ISATAP mechanisms use a new IPv6 interface identifier format that embeds an IPv4 address - this enables automatic IPv6-in-IPv4 tunneling within a site, whether the site uses globally assigned or private IPv4 addresses. The new interface identifier format can be used with both local and global unicast IPv6 prefixes - this enables IPv6 routing both locally and globally. ISATAP mechanisms introduce no impact on routing table size and require no special IPv4 services (e.g., IPv4 multicast).

Comment Further discussion required regarding reservation of ISATAP name. Title Dual Stack Transition Mechanism (DSTM)

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-08.txt

Abstract During the initial deployment of IPv6, hosts in native IPv6 networks will need to maintain connectivity with hosts and/or applications who can only be reached through IPv4. The Dual Stack Transition Mechanism (DSTM) provides a method to assure this connectivity based on the use of IPv4-over-IPv6 tunnels and the temporal allocation of a global IPv4 address to hosts requiring such communication. This document defines the processes and architecture required for this transition mechanism.

Comment



Title Unmanaged Networks Transition Scope

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmanscope-00.txt

Abstract The NGTRANS working group is preparing the transition of the Internet from IPv4 to IPv6 and has devised a number of transition mechanisms. In order to evaluate the suitability of transition mechanisms, we need to define the environment or scope 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 Adopted as WG work item. Title Transition Scenarios for ISP Networks

URL http://www.ietf.org/internet-drafts/draft-mickles-ngtrans-isp-cases-00.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 five specific areas in an effort to better identify specific issues which may arise during a transition to IPv6.

Comment Adopted as WG work item. Title Interaction of Transition Mechanisms

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-interaction-01.txt

Abstract This document discusses the interaction of transition mechanisms that can be involved during the transition phase where both IPv4 and IPv6 will be concurrently used. On one hand, several transition mechanisms have been defined to solve particular transition issues. On the other hand, one can face multiple transition issues and may have to use several transition mechanisms. Since an applicability scope is attached to each transition mechanism, specifying where the mechanism applies, i.e. host, domain or global, this memo aims at identifying cases where multiple transition mechanisms may be involved within the same scope, and what the interaction effects among them can be.

Comment Work on this document is ongoing.



Title Dual Stack Transition Mechanism (DSTM) Overview

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-overview-00.txt

Abstract The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6-only Network. Nodes will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only network and provides a method to allocate a temporary IPv4 Address to IPv6/IPv4 nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment.

Comment Title ISATAP Transition Scenario for Enterprise/Managed Networks

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-isatap-scenario-00.txt

Abstract This document discusses application of the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) as a transition tool for enterprise/managed networks. The enterprise/managed network problem space is described, and the ISATAP transition scenario for enterprise/managed network environments is presented.

Comment This work should be included in the managed networks solutions document.

Title Operational Environments and Transition Scenarios for “Connecting IPv6

Islands across IPv4 Clouds with BGP”

URL http://www.ietf.org/internet-drafts/draft-lefaucheur-bgp-tunnel-transition-00.txt

Abstract This document describes the common operational environments of IPv4 Service Providers wanting to add IPv6 services to their service portfolio but not wanting (yet) to upgrade their IPv4 backbone to IPv6 routing.

Comment This work should be included in the IST transition solutions document. Title NAT64 – NAT46

URL http://www.ietf.org/internet-drafts/draft-durand-ngtrans-nat64-nat46-00.txt

Abstract This document defines two scalable NAT mechanisms, NAT64 to enable IPv6-only devices to initiate communications with unmodified IPv4 only devices and NAT46 to enable IPv4-only devices to initiate communications with IPv6-only devices.




Title Applicability of the Tunnel Setup Protocol (TSP) as an IPv6 Transition Technique

URL http://www.ietf.org/internet-drafts/draft-blanchet-ngtrans-tsp-applicability-00.txt

Abstract There are multiple environments where IPv6 transition techniques can be used. There are multiple IPv6 transition techniques. This document describes the applicability of transition techniques based on the Tunnel Setup Protocol(TSP) used in different environments, such as: provider, enterprise, unmanaged networks, cable-dsl operators, wireless operators, mobile hosts and networks. TSP enables the automation of prefix assignment, DNS delegation and routing preferences. TSP supports IPv6 over IPv4 and IPv4 over IPv6 encapsulations, as well as UDP-IPv4 encapsulation for IPv4 NAT traversals, through automatic NAT discovery.

Comment This is a new personal submission. Title NAT-PT DNS ALG solutions

URL http://www.ietf.org/internet-drafts/draft-hallin-natpt-dns-alg-solutions-01.txt

Abstract There is an ongoing discussion about the impact of IPv4 to IPv6 transition mechanisms such as NAT-PT (RFC2766). [NAT-PT-ISSUES] identifies several problems around the DNS ALG functionality in NAT-PT. This document proposes possible solutions to some of the problems illustrated in [NAT-PT-ISSUES] and to additional issues with the DNS ALG functionality in NAT-PT.

Comment This is a new personal submission. Title TSP-TEREDO: Stateful IPv6 over IPv4 Tunnels with NAT using TSP and

TEREDO

URL http://www.ietf.org/internet-drafts/draft-parent-blanchet-ngtrans-tsp-teredo-00.txt

Abstract Teredo [3] is a stateless mechanism to encapsulate IPv6 traffic in IPv4 when there is an IPv4 NAT between the tunnel endpoints. This document enhances Teredo by providing a stateful IPv6 in IPv4 connexion which enables additional features to be used, like permanent IPv6 address or prefixes. It uses the Tunnel Setup Protocol (TSP) [2] to negotiate the parameters of the tunnel and identify the NAT translation map. TSP also enables negotiation and establishment of prefixes, routing, DNS delegation and other parameters related to the tunnel.




Title Identification of IPv6 Routes that need Tunneling – Use of BGP Extended Community Attribute

URL http://www.ietf.org/internet-drafts/draft-tsenevir-ipv6-bgp-tun-00.txt

Abstract In this document we provide methods to discover and connect native IPV6 clouds that are separated by IPV4 Internet. BGP-MP [2] is used as protocol to discover IPV6 relay routers. BGP-MP(BGP4+) [3] is used to distribute IPV6 routes. Encapsulation of IPV6 presented in [4] is used to tunnel IPv6 traffic across IPV4 Internet. The method presented here is known as 6in4 as opposed to 6to4 [4] or 6over4[5].

Comment This is a new personal submission. Title Teredo: Tunneling IPv6 over UDP through NATs

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-shipworm-07.txt

Abstract We propose here a service that enables nodes located behind one or several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays"; the Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet.

Comment This is a very thorough revision, intended to address the comments from the IESG reviewers, security issues raised by other reviewers, and scalability issues that were discovered through modeling, i.e. that traffic through the server exploded as the proportion of non-Teredo hosts in the Internet increased.

Title An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mtp-02.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 [SIIT] and [NAT-PT].

Comment Title DSTM Ports Option for DHCPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt

Abstract The DSTM Ports Option provides DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts.

Comment



Title Dual Stack Hosts using ‘Bump-in-the-API’ (BIA)

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-bia-05.txt

Abstract This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications. The goal of this mechanism is the same as that of the Bump-in-the-stack mechanism [BIS], but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation.

Comment Approved by IESG for publication as an Experimental RFC. Title DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol (TSP)

URL http://www.ietf.org/internet-drafts/draft-blanchet-ngtrans-tsp-dstm-profile-01.txt

Abstract Based on the actions they perform, The network model presented in DSTM [1] defines three types of equipments: a DSTM server, DSTM nodes and a Tunnel End Point (TEPs). Within this model, a protocol is required for configuration data exchange among these equipments. This document presents a method to perform these actions based on TSP [2].

Comment Title IPv6 over IPv4 profile for Tunnel Setup Protocol (TSP)

URL http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-v6v4profile-01.txt

Abstract This document proposes a tunnel profile to setup IPv6 over IPv4 tunnels to be used with the Tunnel Setup Protocol (TSP) [8].

Comment Title Tunnel Setup Protocol (TSP): A Control Protocol to Setup IPv6 or IPv4

Tunnels

URL http://www.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-01.txt

Abstract This document proposes a control protocol to setup tunnels between a client and a tunnel server or broker. It provides a framework for the negotiation of tunnel parameters between the two entities. It is a generic TCP protocol based on simple XML messaging. This framework protocol enables the negotiation of any kind of tunnel, and is extensible to support new parameters or extensions. The first target application is to setup IPv6 over IPv4 tunnels which is one of the transition mechanism identified by the ngtrans and ipv6 working groups. This IPv6 over IPv4 tunnel setup application of the generic TSP protocol is defined by a profile of the TSP protocol, in a companion document.

Comment



Title BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure

URL http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-bgp-ipv6-vpn-02.txt

Abstract This document describes a method by which a Service Provider may use an MPLS enabled IPv4 backbone to provide Virtual Private Networks for its IPv6 customers. This proposal makes use of the method to build network based VPNs described in the Internet draft "BGP/MPLS VPN" [2547bis]. In BGP/MPLS VPN, MPLS is used to forward packets over the backbone, and "Multiprotocol BGP" is used for distributing VPN routes over the service provider backbone. This document defines an IPv6 VPN address family and describes the route distribution and the MPLS tunnel selection.

Comment Title Transition Mechanisms for IPv6 Hosts and Routers

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-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.

Comment This document obsoletes RFC 2893. Title ISATAP Profile for Tunnel Setup Protocol (TSP)

URL http://www.ietf.org/internet-drafts/draft-templin-ngtrans-isatap-tsp-00.txt

Abstract This document proposes a profile for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) using the Tunnel Setup Protocol (TSP).




3GPP

Key Issues The updated matrix of dependencies on IETF standards is detailed below. Many of the SIP documents, DIAMETER documents, DHCPv6 documents have been marked ‘LATE’ for delivery in Release 5 of the 3GPP architecture.

Standards Development 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 This dependency and priority table is based on the information available as of June 19, 2002.

Title Recommendations for IPv6 in 3GPP Standards

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-02.txt

Abstract This document contains recommendations from the Internet Engineering Task Force (IETF) IPv6 Working Group to the Third Generation Partnership Project (3GPP) community regarding the use of IPv6 in the 3GPP standards. Specifically, this document recommends that the 3GPP: 1. Specify that multiple prefixes may be assigned to each primary PDP context, 2. Require that a given prefix must not be assigned to more than one primary PDP context, and 3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document.

Comment Approved by IESG for publication as Informational RFC.



Title Transition Scenarios for 3GPP Networks

URL http://www.ietf.org/internet-drafts/draft-soininen-ngtrans-3gpp-cases-00.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 of this document.

Comment Adopted as Working Group work item. Title IPv6 Transition Solutions for 3GPP Networks

URL http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-00.txt

Abstract This document describes 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 nodes in other networks, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed.

Comment Further discussion required before this document can be accepted as a WG work item.

Title IPv6 for Some Second and Third Generation Cellular Hosts

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-03.txt

Abstract As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making IPv6 mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. The document lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks.

Comment Revision –03 approved by the IESG for publication as an Informational RFC.



RIR Policy

Key Issues Bob Fink is preparing a proposal to hand over the management of 6bone address space to the RIRs. This would ensure that the 6bone can continue independently of the efforts of individual people, and will also provide a mechanism for integrating the 6bone with the RIR-managed reverse DNS tree. Existing 6bone address space holders will have a ‘sunset period’ in which to apply to their RIR for continuation of their allocation. RIR fees will be waived for 6bone address services provided by RIRs to 6bone members for 1 year after the agreement is made. Thereafter a minimal administration charge may be made.

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.

Comment New policy implemented 1st July, 2002. Title New Values of the “status:” Attribute for inet6num Objects

URL http://www.ripe.net/docs/new-value-status.html

Abstract This document describes the new values of the "status:" attribute for inet6num objects and their impact on database operation.

Comment The RIPE Database server, whois.ripe.net, has been updated to allow the new status attributes specified in the document. The status values of all inet6num objects maintained by the RIPE NCC have been updated as appropriate. The RIPE NCC will use the "ASSIGNED" status value to determine the HD ratio when it receives a request for an additional IPv6 allocation. A request form for additional IPv6 allocations will be published in the near future.

Title IPv6 Address Space Policy for Internet Exchange Points

URL http://www.ripe.net/docs/ripe-256.html

Abstract Internet Exchange Points (IXPs) are used to exchange Internet traffic between different Internet Service Providers (ISPs). Many Exchange Point operators require address space for the peering mesh that is independent from any of the address space in use by member networks.

Comment



Title Policies for Transfer of 6bone Address Management Responsibilities to RIR

URL http://www.apnic.net/meetings/14/sigs/policy/docs/addrpol-out-fink-6bonetoRIR.doc

Abstract This document proposes the transfer of responsibility for administration of 6bone address space (3ffe::/16) to the Regional Internet Address Registries (RIRs). It describes a set of policies and procedures for this transfer, and for the ongoing administration of 6bone address space within the RIR framework.

Comment Comments about this proposal should be sent to the APNIC Address Policy SIG mailing list ([email protected]). The 6bone and other RIRs will be conducting similar reviews within their communities and APNIC will summarise the collective responses, issues, and concerns, made in regard to this proposal. This review process will end on December 31, 2002.



Miscellaneous

Key Issues None.

Standards Development Title IPv6 Node Requirements

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-01.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 Title SMTP operational experience in mixed IPv4/IPv6 environments

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv6-smtp-requirement-06.txt

Abstract This document talks about SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations are necessary in IPv6-capable MX DNS records for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the problems that exist in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.

Comment Title A Protocol for Anycast Address Resolving

URL http://www.ietf.org/internet-drafts/draft-ata-ipv6-anycast-resolving-00.txt

Abstract This document describes a mechanism to realize anycast communication without any modifications of applications and/or underlying protocols. The mechanism, using a DLL (Dynamic Linkable Library) based approach, is called AARP (Anycast Address Resolving Protocol), which resolves the anycast address into the corresponding unicast address prior to establishing the communication. AARP smoothly supports anycasting without change of existing applications.




Title Host Requirements of IPv6 for Low Cost Network Appliances

URL http://www.ietf.org/internet-drafts/draft-okabe-ipv6-lcna-minreq-02.txt

Abstract Resource limitations and cost constraints associated with small-embedded devices make it difficult to implement the entire IPv6 specification. We call such non-PC embedded devices (e.g. game-machines, AV devices, sensors, digital cameras, LCD projectors, and home appliances) "Low Cost Network Appliances", and define the IPv6 host requirements for them. In this document, we will also point out several items to be discussed for the deployment of IPv6 on LCNAs.

Comment Title Survey of IPv4 Addresses in Currently Deployed IETF Standards

URL http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-02.txt

Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF 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 In Last Call for publication as an Informational RFC. Any further discussion will take place in v6ops.

Title Multi-link Subnet Support in IPv6

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-multilink-subnets-00.txt

Abstract Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. This document introduces the concept of a "multilink subnet", defined as a collection of independent links, connected by routers, but sharing a common subnet prefix. It then specifies the behaviour of multilink subnet routers so that no changes to host behaviour are needed.

Comment



Title Generic Packet Tunneling in IPv6 Specification

URL http://www.ietf.org/internet-drafts/draft-ietf-ipv6-tunnel-v02-00.txt

Abstract This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others.

Comment Revision to RFC2473 Title Defining and Locating IPv6 Address Blocks using the Internet Resource

Query Service

URL http://www.ietf.org/internet-drafts/draft-ietf-crisp-lw-ipv6-00.txt

Abstract This document defines LDAP schema and searching rules for IPv6 addresses and address blocks, in support of the Internet Resource Query Service described in [ldap-whois].

Comment Title Fault Tolerance and Load Balance Services using IPv6 Anycast

URL http://www.ietf.org/internet-drafts/draft-ettikan-ipngwg-fault-tolarance-anycast-00.txt

Abstract This document describes how fault tolerant anycast service can be achieved using IPv6 anycast service. Communication between an anycast client and an anycast server is required as indicated in [ANALYSIS]. While, proposed host based anycast MLD [HOSTANY] or other anycast group address management scheme is in place for this fault tolerant anycast service to take place.




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

Documents

D5.1.2 - ipv6-es.com · Standardisation of IPv6 technology is now starting to adopt an ‘operations’ perspective, as evidenced by the re-chartering of the DNS Operations Working