Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
draft-ietf-seamoby-iana-02
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4065.
|
|
|---|---|---|---|
| Author | James Kempf | ||
| Last updated | 2015-10-14 (Latest revision 2004-06-09) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Experimental | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4065 (Experimental) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Allison J. Mankin | ||
| Send notices to | (None) |
draft-ietf-seamoby-iana-02
James Kempf
Internet Draft DoCoMo Labs USA
Document: draft-ietf-seamoby-iana-02.txt
Expires: December, 2004 June, 2004
Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
Status of this Memo
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Seamoby Candidate Access Router Discovery protocol and Context Transfer
Protocol are experimental protocols designed to accelerate IP handover
between wireless access routers. These protocols require IANA allocations
for ICMP type and options, SCTP Payload Protocol Identifiers, port numbers,
and registries for certain formatted message options. This document contains
instructions to IANA about what allocations are required for the Seamoby
protocols. The ICMP subtype extension format for Seamoby has additionally
designed so that it can be utilized by other experimental mobility
protocols, and the SCTP port number is also available for other experimental
mobility protocols.
Table of Contents
1.0 Introduction..........................................................2
2.0 Common IPv4 and IPv6 Allocations......................................2
3.0 IPv4 Allocations......................................................2
4.0 IPv6 Allocations......................................................3
5.0 Candidate Access Router Discovery Protocol Registries.................3
Kempf Expires November, 2004 [Page 1]
Internet Draft Seamoby IANA Allocations May, 2004
6.0 Context Transfer Profile Type Registry................................4
7.0 Context Transfer Protocol Authorization Token Calculation Algorithm...4
8.0 ICMP Experimental Mobility Subtype Format and Registry................5
9.0 Utilization by Other Experimental Mobility Protocols..................5
10.0 Normative References................................................6
11.0 Security Considerations.............................................6
12.0 IANA Considerations.................................................6
13.0 Author Information..................................................6
14.0 Full Copyright Statement............................................6
15.0 Intellectual Property...............................................7
16.0 Acknowledgement.....................................................7
1.0 Introduction
The Seamoby Candidate Access Router Discovery (CARD) protocol [CARD] and
Context Transfer Protocol (CTP) [CTP] are experimental protocols designed to
accelerate IP handover between wireless access routers. These protocols
require IANA allocations for ICMP options and type, SCTP Payload Protocol
Identifiers and port number, and establishment of registries for certain
formatted message options. Because the protocols are experimental, there is
no guarantee that they will ever see widespread deployment in their current
form. Consequently, it seems prudent to conserve Internet numbering
resources that might be needed for other protocols which could see wider
deployment. This draft contains instructions to IANA for the Seamoby
protocols. Additionally, the ICMP subtype extension format has been designed
so that it could be used by other experimental mobility protocols.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Allocation policy names Specification Required, IETF Consensus Action, and
Designated Expert are to be interpreted as described in RFC 2434 [RFC2434].
2.0 Common IPv4 and IPv6 Allocations
IANA SHALL assign SCTP port number TBD1 for use by experimental mobility
protocols such as Seamoby. See Section 5.2.1 of [CARD] for a description of
inter-access router CARD protocol use of SCTP, and Section 3.1 of [CTP] for
a description of the inter-access router CTP use of SCTP.
IANA SHALL assign SCTP Payload Protocol Identifier (PPI) TBD2, designated
"CTP", for the Context Transfer Protocol, and SCTP Payload Protocol
Identifier TBD3, designated "CARD", for the Candidate Access Router
Discovery protocol. These are used to differentiate inter-router CARD and
CTP messages on the SCTP port. The allocation policy for new PPI numbers is
the method of IETF Consensus Action.
3.0 IPv4 Allocations
IANA SHALL assign ICMP type TBD4 for IPv4 identifying ICMP messages utilized
by experimental mobility protocols such as Seamoby. See Section 5.1.1 of
Kempf Expires November 2004 [Page 2]
Internet Draft Seamoby IANA Allocations May, 2004
[CARD] for a description of experimental mobility CARD ICMP messages and
Section 3.2 of [CTP] for the CTP ICMP messages, specified by Seamoby. See
Section 9.0 of this document for a description of the experimental mobility
protocol ICMP subtype format and initial allocations.
IANA SHALL assign Mobile IPv4 Foreign Agent Discovery [RFC3220] option type
codes for the following:
Code Purpose Reference
--------------------------------------------------------------
TBD5 CARD MN-AR signature option Section 6.4 of [CARD]
TBD6 CARD Request option Section 5.1.2.1 of [CARD]
TBD7 CARD Reply option Section 5.1.2.2 of [CARD]
4.0 IPv6 Allocations
IANA SHALL assign ICMP type code TBD8 for IPv6 identifying ICMP messages
utilized by experimental mobility protocols such as Seamoby. See Section
5.1.1 of [CARD] for a description of experimental mobility CARD ICMP
messages and Section 3.2 of [CTP] for the CTP ICMP messages, specified by
Seamoby. See Section 9.0 of this document for a description of the
experimental mobility protocol subtype format and initial allocations.
IANA SHALL assign IPv6 RFC 2461 Neighbor Discovery [RFC2461] option type
codes for the following:
Code Purpose Reference
--------------------------------------------------------------
TBD9 CARD Request option Section 5.1.2.1 of [CARD]
TBD10 CARD Reply option Section 5.1.2.2 of [CARD]
5.0 Candidate Access Router Discovery Protocol Registries
For CARD, two new registries are created that IANA is to maintain, named:
1) The AVP Type Registry,
2) The Layer 2 Access Technology Identifier Registry.
These are described in the following subsections.
5.1 AVP Type Registry
The AVP Type Registry allows future expansion of the CARD AVP type space to
include new AVPs. AVP Type codes are 16 bit unsigned integers. See Section
5.1.4 of [CARD] for a description of AVPs.
The registry SHALL be initially populated with the following table:
AVP Name Type Code
----------------------------------------------
RESERVED 0x00
Future allocations of AVP type codes are made through Expert Review, as
defined in RFC 2434.
Kempf Expires November 2004 [Page 3]
Internet Draft Seamoby IANA Allocations May, 2004
5.2 Layer 2 Access Technology Identifier Registry
The Layer 2 Access Technology Identifier registry allows the registration of
type codes to uniquely identify specific access technologies in the L2-Type
field of the CARD L2 ID sub-option. L2 ID codes are 16 bit unsigned
integers. See Section 5.1.3.1 of [CARD] for a description of the CARD L2 ID
sub-option.
The registry SHALL initially be populated with the following table:
Layer 2 Access Technology Type Code
----------------------------------------------
RESERVED 0x00
IEEE 802.3 (Ethernet) 0x01
IEEE 802.11a 0x02
IEEE 802.11b 0x03
IEEE 802.11g 0x04
IEEE 802.15.1(Bluetooth) 0x05
IEEE 802.15.3 0x06
IEEE 802.15.4 0x07
IEEE 802.16 0x08
Future allocation of Layer 2 Access Technology identifiers are made by the
method of Specification Required as defined in RFC 2434. All requests for
allocations MUST be accompanied by a reference to a technical document in
which the design of the Layer 2 access technology is described.
6.0 Context Transfer Profile Type Registry
CTP requires IANA to maintain a registry named the Context Transfer Profile
Type Registry, which is a registry of context Feature Profile Type
identifiers. Feature Profile Type identifiers are 16 bit unsigned integers
that identify particular types of feature contexts. See Section 2.4 of [CTP]
for a description of how contexts are carried in CTP.
The registry SHALL initially be populated with the following table:
Context Profile Type Code
----------------------------------------------
RESERVED 0x00
IPv6 Multicast Listener Context 0x01
Future allocations of Feature Profile Type codes are made through Expert
Review, as defined in RFC 2434.
7.0 Context Transfer Protocol Authorization Token Calculation Algorithm
In Section 2.5.4 of [CTP], CTP requires an authorization token calculation
algorithm indicator. Currently, the only indicator defined is 0x1, for
HMAC_SHA1. Additional algorithms may be added by the method of Specification
Required [RFC2434].
Kempf Expires November 2004 [Page 4]
Internet Draft Seamoby IANA Allocations May, 2004
8.0 ICMP Experimental Mobility Subtype Format and Registry
The ICMP Experimental Mobility Type is utilized by CARD and CTP in the
following way. The interpretation of the Code field is as defined by the
relevant ICMP standard for IPv4 and IPv6, and does not change. The protocols
are free to utilize the Code for their own purposes. The ICMP Experimental
Mobility Type defines a one octet subtype field within the ICMP Reserved
field, which identifies the specific protocol. The ICMP header for the
Experimental Mobility Type is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type For IPv4, TBD4; for IPv6 TBD8
Code As defined by the relevant ICMP specification, and
free for use by the Experimental Mobility protocol.
Checksum ICMP checksum
Subtype One octet subtype code identifying the Experimental
Mobility protocol
Reserved Unless otherwise defined by the Experimental Mobility
protocol, set to zero by the sender and ignored by
the receiver.
Options As defined by the Experimental Mobility protocol.
IANA SHALL maintain a registry of one octet unsigned integer subtype codes
for the Experimental Mobility protocols called the Experimental Mobility
Protocol Subtype Registry.
Initial allocations in the registry SHALL be established as follows:
Protocol/Message Subtype Reference
----------------------------------------------------------------------
CARD 0 Section 5.1.1 of [CARD]
CTP 1 Section 3.2 of [CTP]
Subsequent allocations of subtype codes SHALL be done by the method of
Specification Required and IESG Review as defined in RFC 2434.
9.0 Utilization by Other Experimental Mobility Protocols
Kempf Expires November 2004 [Page 5]
Internet Draft Seamoby IANA Allocations May, 2004
The ICMP Experimental Mobility type code and SCTP port are available for
other experimental mobility protocols to utilize. Other experimental
mobility protocols MAY define additional ICMP messages that utilize the code
points under the Experimental Mobility ICMP type, and MAY define protocols
that utilize additional SCTP PPI numbers for the Experimental Mobility
protocol port.
10.0 Normative References
[CARD] Liebsch, M., Singh, A. (editors), Chaskar, H., Funato, D., and Shim,
Ensoo, " Candidate Access Router Discovery", Internet Draft, work in
progress.
[CTP] Loughny, J. (editor), Nahkjiri, M., Perkins, C., and Koodli, R.,
"Context Transfer Protocol", Internet Draft, work in progress.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
[RFC2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October, 1998.
[RFC2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December, 1998.
[RFC3220] Perkins, C. (editor),"IP Mobility Support for IPv4", RFC 3220,
January, 2002.
11.0 Security Considerations
There are no security considerations associated with this document.
12.0 IANA Considerations
This entire document is about IANA considerations.
13.0 Author Information
James Kempf Phone: +1 408 451 4711
DoCoMo Labs USA Email: kempf@docomolabs-usa.com
181 Metro Drive
Suite 300
San Jose, CA
95110
14.0 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS"
basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED
BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
Kempf Expires November 2004 [Page 6]
Internet Draft Seamoby IANA Allocations May, 2004
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
15.0 Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to pertain
to the implementation or use of the technology described in this document or
the extent to which any license under such rights might or might not be
available; nor does it represent that it has made any independent effort to
identify any such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of
licenses to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the IETF on-
line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights that
may cover technology that may be required to implement this standard.
Please address the information to the IETF at ietf-ipr@ietf.org.
16.0 Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet
Society.
Kempf Expires November 2004 [Page 7]