One document matched: draft-narten-ipv6-iana-considerations-00.txt

INTERNET-DRAFT                                             Thomas Narten
<draft-narten-ipv6-iana-considerations-00.txt>                       IBM
                                                        October 22, 2002

     IANA Allocation Guidelines for Values in IPv6 and Related Headers

              <draft-narten-ipv6-iana-considerations-00.txt>


Status of this Memo
   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document provides guidelines to IANA on the procedures for
   assigning values for various IPv6-related fields. This document
   updates and replaces the IPv6-related guidelines in RFC 2780.

Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    2

   2.  IANA Considerations for fields in the IPv6 header........    2
      2.1.  IPv6 Version field..................................    2
      2.2.  IPv6 Traffic Class field............................    3
      2.3.  IPv6 Next Header field..............................    3
      2.4.  IPv6 Source and Destination Unicast Addresses.......    3
      2.5.  IPv6 Global Unicast Addresses.......................    3
      2.6.  IPv6 Anycast Addresses..............................    3



draft-narten-ipv6-iana-considerations-00.txt                    [Page 1]

INTERNET-DRAFT                                          October 22, 2002


      2.7.  IPv6 Unassigned and Reserved IPv6 Address Ranges....    4
      2.8.  IPv6 Multicast Addresses............................    4
      2.9.  IPv6 Hop-by-Hop and Destination Option Fields.......    4
      2.10.  ICMPv6.............................................    4
         2.10.1.  IPv6 Neighbor Discovery Fields................    5

   3.  IANA Considerations......................................    5

   4.  Security Considerations..................................    5

   5.  Acknowledgments..........................................    5

   6.  Normative References.....................................    5

   7.  Informative References...................................    6


1.  Introduction

   IANA allocation guidelines for the assignment of values in IPv6
   header fields were originally defined in RFC 2780 [RFC2780]. This
   document revises and updates the IPv6 aspects of RFC 2780, taking
   into account updates to existing IPv6 documents as well as the
   creation of new ones that have taken place since RFC 2780 was issued.

   The terms "Specification Required", "Expert Review", "IESG Approval",
   "IETF Consensus", and "Standards Action", are used in this memo to
   refer to the processes described in [CONS].


2.  IANA Considerations for fields in the IPv6 header

   The IPv6 header [V6] contains the following fields that carry values
   assigned from IANA-managed name spaces: Version (by definition always
   6 in IPv6), Traffic Class, Next Header, Source and Destination
   Address.  In addition, the IPv6 Hop-by-Hop Options and Destination
   Options extension headers include an Option Type field with values
   assigned from an IANA-managed name space.


2.1.  IPv6 Version field

   The IPv6 Version field is always 6.








draft-narten-ipv6-iana-considerations-00.txt                    [Page 2]

INTERNET-DRAFT                                          October 22, 2002


2.2.  IPv6 Traffic Class field

   The IPv6 Traffic Class field is a 6-bit Differentiated Services field
   (DSField) as defined in [DIFF,DIFF2] and a 2-bit field as defined in
   RFC 3168 [ECN].  The IPv4 Type-of-Service (TOS) field [IPv4] and the
   IPv6 traffic class field [IPV6] are now defined to have identical
   meanings and there are no IPv6-specific IANA considerations for these
   fields.


2.3.  IPv6 Next Header field

   The IPv6 Next Header field carries values from the same name space as
   the IPv4 Protocol name space. These values are allocated as discussed
   in Section 4.3 of [RFC 2780].


2.4.  IPv6 Source and Destination Unicast Addresses

   The IPv6 Source and Destination address fields both use the same
   values and are described in [V6AD].  All addresses except those
   specifically assigned for other uses are treated as global unicast
   addresses.

   In some cases, it is necessary to assign IPv6 address space for
   purposes other than the assignment of globally unique address space
   to physical devices.  Examples of such assignments include IPv6
   mapped addresses, multicast address ranges, link-local addresses,
   anycast subnet addresses, etc.  Assignments for such purposes are
   made following a Standards Action or IESG Approval.


2.5.  IPv6 Global Unicast Addresses

   The IANA was given responsibility for all IPv6 address space by the
   IAB in [V6AA]. The IANA, in turn, further delegates allocation of
   address space to the Regional Internet Registries (e.g., APNIC, ARIN,
   and RIPE) [V6SUBTLA].  At present, IANA has been asked to restrict
   its allocation of global addresses space to that starting with a
   binary value of 001 [V6AA] (i.e., roughly 1/8th of the total).


2.6.  IPv6 Anycast Addresses

   IPv6 anycast addresses are defined in [V6AD].  Anycast addresses are
   allocated from the unicast address space and are syntactically
   indistinguishable from unicast addresses.  Assignment of IPv6 Anycast
   subnet addresses follow the process described in [V6SUB].  Assignment



draft-narten-ipv6-iana-considerations-00.txt                    [Page 3]

INTERNET-DRAFT                                          October 22, 2002


   of other IPv6 Anycast addresses follows the process defined in
   section 2.4 above.


2.7.  IPv6 Unassigned and Reserved IPv6 Address Ranges

   The assignment of values in each of the "unassigned" and "reserved"
   Address Ranges requires IESG Approval or Standards Action processes.


2.8.  IPv6 Multicast Addresses

   IPv6 multicast addresses are defined in [V6AD].  Guidelines for
   assigning IPv6 multicast addresses are described in [RFC3306]


2.9.  IPv6 Hop-by-Hop and Destination Option Fields

   8-bit IPv6 Hop-by-Hop Option and Destination Option types consist of
   three components [IPV6]:

     act - a 2-bit action type defining how the option is to be
          processed if it is not understood.

     chg - a 1-bit indication of whether or not the value of the option
          when it reaches its destination can be predicted. The IPsec
          Authentication Header (AH) [IPSEC] uses this bit to determine
          whether an option should be included in its message intergrity
          checks.

     rest - the rest of the option

   Values for the IPv6 Hop-by-Hop Options and Destination Options fields
   are allocated through an IESG Approval, IETF Consensus or Standards
   Action process. Note that the requestor of an option must specify the
   value for the "act" and "chg" portions of the option type value; IANA
   assigns a unique value for "rest".


2.10.  ICMPv6

   The assignment of ICMPv6 values is defined in [ICMPV6]. (XXX text is
   not in that ID yet, it also needs to talk about split between error
   and info messages).







draft-narten-ipv6-iana-considerations-00.txt                    [Page 4]

INTERNET-DRAFT                                          October 22, 2002


2.10.1.  IPv6 Neighbor Discovery Fields

   IPv6 Neighbor Discovery messages [NDV6] are ICMPv6 messages using
   type values 133-137. At present, all Neighbor Discovery messages use
   a Code value of 0. Assignment of type values require a Standards
   Action.

   Some IPv6 Neighbor Discovery messages carry optional Neighbor
   Discovery Option fields [NDV6], which consist of type-length-value
   triples. Additional Neighbor Discovery Option Type values are
   assigned following Standards Action or IESG Approval.


3.  IANA Considerations

   This document clarifies the IANA considerations for a number of
   IPv6-related protocols.

   In addition, experience with IPv4 has shown that it is useful to
   reserve an address block for documentation purposes that will never
   be assigned for actual use in a network [DOC]. Such addresses can
   safely be used in documentation, without the worry that someone will
   accidentally (and incorrectly) configure them on a real network and
   cause traffic intended for the legitimate owner of those addresses to
   be impacted.

   This document reserves the IPv6 address block XXXX::/32 for
   documentation purposes.


4.  Security Considerations

   This document has no known security implications.


5.  Acknowledgments

   This document was started by copying text from RFC 2780 authored by
   Scott Bradner and Vern Paxson.


6.  Normative References

   [RFC2780] IANA Allocation Guidelines For Values In the Internet
           Protocol and Related Headers. S. Bradner, V. Paxson. March
           2000, RFC 2780.

   [CONS] Guidelines for Writing an IANA Considerations Section in RFCs.



draft-narten-ipv6-iana-considerations-00.txt                    [Page 5]

INTERNET-DRAFT                                          October 22, 2002


           T. Narten, H. Alvestrand. October 1998. RFC 2434.

   [ICMPV6] draft-ietf-ipngwg-icmp-v3-02.txt

   [V6AA] IAB, IESG, "IPv6 Address Allocation Management", RFC 1881,
           December 1995.

   [V6AD] Hinden, R. and S. Deering, draft-ietf-ipngwg-addr-arch-
           v3-10.txt.

   [V6SUB] Reserved IPv6 Subnet Anycast Addresses. D. Johnson, S.
           Deering.  March 1999. RFC 2526.

   [V6SUBTLA] Initial IPv6 Sub-TLA ID Assignments. R. Hinden, S.
           Deering, R.  Fink, T. Hain. RFC 2928, September 2000.

   [RFC3306] Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman,
           D.  Thaler. August 2002. RFC 3306.



7.  Informative References

   [DOC] draft-iana-special-ipv4-05.txt

   [ECN] The Addition of Explicit Congestion Notification (ECN) to IP.
           K.  Ramakrishnan, S. Floyd, D. Black. September 2001. RFC
           3168.

   [DIFF] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
           the Differentiated Services Field (DS Field) in the IPv4 and
           IPv6 Headers", RFC 2474, December 1998.

   [DIFF2] New Terminology and Clarifications for Diffserv. D. Grossman.
           April 2002. RFC 3260.

   [IPSEC] 1825 Security Architecture for the Internet Protocol. R.
           Atkinson.  August 1995. RFC 1825.

   [IPV4] Internet Protocol. J. Postel. Sep-01-1981. RFC 791.

   [NDV6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
           for IP Version 6 (IPv6)", RFC 2461, December 1998.








draft-narten-ipv6-iana-considerations-00.txt                    [Page 6]

INTERNET-DRAFT                                          October 22, 2002


8.
   Authors' Addresses

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com








































draft-narten-ipv6-iana-considerations-00.txt                    [Page 7]