As per Relevance of the word copyright, we have this rfc below:











Network Working Group B.
Request for Comments: 3228 AT&T
BCP: 57 February 2002
Category: Best Current


IANA Considerations
IPv4 Internet Group Management Protocol (IGMP

Status of this

This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited

Copyright

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



This memo requests that the IANA create a registry for fields in
IGMP (Internet Group Management Protocol) protocol header,
provides guidance for the IANA to use in assigning parameters
those fields

Table of

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

1.

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

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






Fenner Best Current Practice [Page 1]

RFC 3228 IANA Considerations for IPv4 IGMP February 2002


2. IANA Considerations for fields in the IPv4 IGMP

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

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

3. Assignments for testing and

Instead of suggesting temporary assignments as in [3], this
follows the lead of [4] and assigns a range of values
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
values

4. Security

Security analyzers such as firewalls and network intrusion
monitors often rely on unambiguous interpretations of the
described in this memo. As new values for the fields are assigned
existing security analyzers that do not understand the new values
fail, resulting in either loss of connectivity if the
declines to forward the unrecognized traffic, or loss of security
it does forward the traffic and the new values are used as part of
attack. This vulnerability argues for high visibility (which
Standards Action and IETF Consensus processes ensure) for
assignments whenever possible

5. Normative

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

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







Fenner Best Current Practice [Page 2]

RFC 3228 IANA Considerations for IPv4 IGMP February 2002


6. Informative

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

[4] Narten, T., "Assigning Experimental and Testing
Considered Useful", Work in Progress

7. Author's

Bill
AT&T Labs --
75 Willow
Menlo Park, CA 94025


EMail: fenner@research.att.

































Fenner Best Current Practice [Page 3]

RFC 3228 IANA Considerations for IPv4 IGMP February 2002


8. Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

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

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



Funding for the RFC Editor function is currently provided by
Internet Society



















Fenner Best Current Practice [Page 4]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum