[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 RFC 3228

MAGMA Working Group                              Bill Fenner
INTERNET-DRAFT                                 AT&T Research
Expires: April 2002                             October 2001


                      IANA Considerations for IGMP
                   draft-ietf-magma-igmp-iana-00.txt

Status of this Document

This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt

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


This document is a product of the MAGMA Working Group.  Comments should
be addressed to the authors, or the mailing list at
magma@innovationslab.net.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.

                                Abstract

This memo requests that the IANA create a registry for fields in the
IGMP protocol header, and provides guidance for the IANA to use in
assigning parameters for those fields.









Fenner                                                          [Page 1]

INTERNET-DRAFT             Expires: April 2002              October 2001


                           Table of Contents


1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . .   2
2. IANA Considerations for fields in the IPv4 IGMP
header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
3. Assignments for testing and experimentation . . . . . . . . . . .   2
4. Security Considerations . . . . . . . . . . . . . . . . . . . . .   2
5. References. . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
6. Current IGMP Type/Code Assignments. . . . . . . . . . . . . . . .   3
7. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .   6
8. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

This memo requests that the IANA create a registry for fields in the
IGMP protocol header.

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 [4].

2.  IANA Considerations for fields in the IPv4 IGMP header

The IPv4 IGMP header [1] contains the following fields that carry values
assigned from IANA-managed name spaces: Type and Code. Code field values
are defined relative to a specific Type value.

Values for the IPv4 IGMP Type fields are allocated using an IESG
Approval or Standards Action processes. Code Values for existing IPv4
IGMP Type fields are allocated using IESG Approval or Standards Action
processes. The policy for assigning Code values for new IPv4 IGMP Types
should be defined in the document defining the new Type value.

3.  Assignments for testing and experimentation

Instead of suggesting temporary assignments as in [2], this document
follows the lead of [3] and assigns a range of values for experimental
use.  The IGMP Code values 240-255 inclusive (0xf0 - 0xff) are reserved
for protocol testing and experimentation.

Systems should silently ignore IGMP messages with unknown Code values.

4.  Security Considerations

Security analyzers such as firewalls and network intrusion detection
monitors often rely on unambiguous interpretations of the fields
described in this memo.  As new values for the fields are assigned,



Fenner                                              Section 4.  [Page 2]

INTERNET-DRAFT             Expires: April 2002              October 2001


existing security analyzers that do not understand the new values may
fail, resulting in either loss of connectivity if the analyzer declines
to forward the unrecognized traffic, or loss of security if it does
forward the traffic and the new values are used as part of an attack.
This vulnerability argues for high visibility (which the Standards
Action and IETF Consensus processes ensure) for the assignments whenever
possible.

5.  References

[1] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
     2236, November 1997

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

[3] Narten, T. "Assigning Experimental and Testing Numbers Considered
     Useful", draft-narten-iana-experimental-allocations-00.txt, July
     2001.

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.




























Fenner                                              Section 6.  [Page 3]

INTERNET-DRAFT             Expires: April 2002              October 2001


6.  Current IGMP Type/Code Assignments

This section is suitable for use as initial version of the IANA's igmp-
parameters file.  It is to be removed before publication as RFC.

One open issue: is there a place to publish the not-a-standard PIMv1
spec?  It's an I-D that's been expired for 6 years, but is arguably the
only place that the packet formats for PIMv1 are defined.  Can this spec
be placed in a stable place at the RFC-editor site without giving it any
kind of official status?

IGMP TYPE NUMBERS

The Internet Group Message Protocol (IGMP) has many messages that
are identified by a "type" field.

Note that the original definition of IGMP in RFC1112 divided this
field into two 4-byte values, "version" and "type".  This was
decided to be too restrictive, so the fields were combined into a
single 8-bit type space.

Type      Name                                    Reference
----      ----------------------                  ---------
0x11      IGMP Membership Query                   [RFC1112]
0x12      IGMPv1 Membership Report                [RFC1112]
0x13      DVMRP                                   [...]
0x14      PIM version 1                           [PIMv1]
0x15      Cisco Trace Messages
0x16      IGMPv2 Membership Report                [RFC2236]
0x17      IGMPv2 Leave Group                      [RFC2236]
0x1e      Multicast Traceroute Response           [Fenner]
0x1f      Multicast Traceroute                    [Fenner]
0x22      IGMPv3 Membership Report                [...]
0xf0-0xff Reserved for experimentation            [...]


Many of these IGMP types have a "code" field.  Here we list the types
again with their assigned code fields.

Type      Name                                    Reference
----      -------------------------               ---------
0x11      IGMP Membership Query                   [RFC1112]

          Codes
              0  IGMP Version 1
          1-255  IGMP Version 2 or above Max Response Time

0x12      IGMPv1 Membership Report                [RFC1112]



Fenner                                              Section 6.  [Page 4]

INTERNET-DRAFT             Expires: April 2002              October 2001


0x13      DVMRP                                   [...]

          Codes
              1  Probe
              2  Route Report
              3  Old Ask Neighbors
              4  Old Neighbors Reply
              5  Ask Neighbors
              6  Neighbors Reply
              7  Prune
              8  Graft
              9  Graft Ack

0x14      PIM version 1                           [PIMv1]

          Codes
              0  Query
              1  Register
              2  Register-Stop
              3  Join/Prune
              4  RP-Reachable
              5  Assert
              6  Graft
              7  Graft Ack
              8  Mode

0x16      IGMPv2 Membership Report                [RFC2236]

0x17      IGMPv2 Leave Group                      [RFC2236]

0x1e      Multicast Traceroute Response           [Fenner]

0x1f      Multicast Traceroute                    [Fenner]

0x22      IGMPv3 Membership Report                [...]

0xf0-0xff Reserved for experimentation            [...]


REFERENCES
----------

[RFC1112] Deering, S., "Host extensions for IP multicasting", RFC 1112,
          Stanford University, August 1989.

[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2",
          RFC 2236, Xerox PARC, November 1997.




Fenner                                              Section 6.  [Page 5]

INTERNET-DRAFT             Expires: April 2002              October 2001


[PIMv1]   Estrin, D. et al, "Protocol Independent Multicast (PIM):
          Protocol Specification", no stable reference known,
          draft-ietf-idmr-pim-spec-01.ps, January 1995.

[...]     Pusateri, T.,  "DVMRP Version 3", work in progress,
          Juniper Networks, July? 2001.

[...]     Cain, B., S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan,
          "Internet Group Management Protocol, Version 3", work in
          progress, July? 2001.

[...]     Fenner, W., "IANA Considerations for IGMP", work in progress,
          October 2001.

PEOPLE
------

[Fenner] Bill Fenner, <fenner@research.att.com>

[]



7.  Author's Address


Bill Fenner
AT&T Labs -- Research
75 Willow Rd
Menlo Park, CA 94025
USA

Email: fenner@research.att.com


8.  Full Copyright Statement

Copyright (C) The Internet Society (2001). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in



Fenner                                              Section 8.  [Page 6]

INTERNET-DRAFT             Expires: April 2002              October 2001


which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.






































Fenner                                              Section 8.  [Page 7]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/