[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Internet Draft Pekka Pkk÷nen
Document:draft-paakkonen-nemo-prefix-delegation-00.txt Juhani Latvakoski
Expires: September 2003
March 2003
Mobile Network Prefix Delegation extension for Mobile IPv6
draft-paakkonen-nemo-prefix-delegation-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This draft proposes a dynamic Mobile Network Prefix (MNP) delegation
extension for Mobile IPv6 protocol to enable MNP delegation for
mobile networks. A MNP is an IPv6 prefix used in a mobile network.
The extension supports dynamic delegation, return, refreshing and
updating operations related to MNP delegation operations between a
Mobile Router (MR) of a mobile network and the MR's Home Agent (HA).
This extension is proposed, because there is a lack for a dynamic MNP
delegation protocol related to mobile networks, and currently MNPs have
to be assigned statically to enable mobile networking.
Pkk÷nen et al. Expires September 2003 [Page i]
INTERNET-DRAFT MNP Delegation March 2003
Table of contents
Abstract i
1. Introduction i
2. Terms 1
3. Terminology 1
4. Overview 1
4.1. MIPv6 extension overview..................................... 2
5. Protocol .......................................................... 3
5.1. Operational environment ..................................... 3
5.2. Messages .................................................... 3
5.2.1 MNP Delegation Message ................................. 4
5.3. Options ..................................................... 6
5.3.1. MNP Option ............................................ 6
5.3.2. MNP Data Option ....................................... 7
5.4. Operation ................................................... 8
5.4.1. MNP Query sequence .................................... 8
5.4.2. MNP Delegation sequence .............................. 11
5.4.3. MNP Refresh sequence ................................. 12
5.4.4. MNP Return sequence .................................. 13
5.4.5. MNP Update sequence .................................. 15
5.5. Examples ................................................... 17
5.5.1. MNP Query sequence ................................... 17
5.5.2. MNP Delegation sequence .............................. 19
5.5.3. MNP Update sequence .................................. 21
6. Constants 23
7. Security issues 23
Acknowledgements 23
References 23
Author's addresses 24
Full Copyright Statement 25
1. Introduction
This document describes how one or more Mobile Network Prefixes (MNP)
can be delegated to a mobile network with extensions to Mobile IPv6 [2]
protocol. MNP is an IPv6 prefix used in a mobile network. By using the
extensions proposed in this document it is possible to dynamically
delegate MNPs for a mobile network. MNP Delegation is executed between a
Mobile Router (MR) of a mobile network and its Home Agent (HA). MR
acquires, refreshes and returns MNPs from its HA according to its needs.
HA controls the delegation of MNPs to MRs. HA can also inform about new
Pkk÷nen et al. Expires September 2003 [Page 1]
INTERNET-DRAFT MNP Delegation March 2003
valid and preferred lifetimes regarding the delegated MNPs. The
extension described in this document is needed, because there is no
mechanism for dynamic delegation of MNPs to mobile networks, but instead
MNPs have to be assigned statically to mobile networks.
2. Terms
The terminology used in this document is defined in an other Internet
draft [3]. In addition to this, some new terms are defined.
MNP Requestor = MR which delegates MNPs from its HAs.
MNP Delegator = HA which delegates MNPs to a MR.
MNP Delegation = The delegation of a MNP from a HA to a MR.
MNP Refreshing = MNP delegation lease extension initiated by the MR.
MNP Returning = Returning of a MNP from MR to its HA after the initial
MNP delegation of the MNP. This operation is executed when the MR no
longer needs the delegated MNP, and returns it back to the HA which
originally delegated the MNP.
MNP Updating = The delegated MNP might change for example because
of renumbering operations at the HA. This function is used to inform
MR of valid and preferred lifetime changes regarding the leased MNP.
Transaction identifier = An identifier used to match a request message
to a response. This kind of message exchange forms a transaction between
communicating parties.
3. Terminology
The keywords "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 [1].
4. Overview
The environment for this solution is defined in the NEMO working
group (WG) [4]. The NEMO WG is developing a solution for a mobile
network, which is based on one or more MRs connecting a mobile network
to the Internet. The basic approach is to use Mobile IPv6 and
bidirectional tunneling between the MR and its HA to enable transparent
session mobility for the Mobile Nodes (MN) of the mobile network. The
MNP is an IPv6 prefix of arbitrary length, which identifies an entire
mobile network within the Internet topology [3]. This document focuses
on the dynamic MNP delegation for a NEMO-network. Dynamic MNP assignment
for a NEMO-network using MIPv6 is desirable for the following reasons:
1. Static MNP assignment for a mobile network is laborious
- If a MNP will be statically allocated for each mobile network, it
Pkk÷nen et al. Expires September 2003 [Page 2]
INTERNET-DRAFT MNP Delegation March 2003
demands a great deal of management and configuration work related to
MNPs. There might be millions of mobile networks in the future and
manual allocation of a MNP for each mobile network is laborious.
2. A mobile network may need a MNP in an ad-hoc way
- MNP allocation might be managed using Router Renumbering for IPv6 [5].
But the mobile network could be formed in an ad-hoc way in which case
the MR initially does not have a MNP and requests for it dynamically. In
this case [5] is insufficient and a dynamic protocol for MNP delegation
is needed. This requirement assumes that there is a need for dynamic
mobile network formation.
3. Lifetime of the mobile network is not necessarily infinite
- Use cases of such situations are expected to occur in Personal Area
Networks (PAN), which require mobile networking capabilities only for a
short time. Addressing resources are wasted, if the delegated MNP of
the mobile network is not used. The MNP should be possible to be
returned dynamically to the MNP delegator, after it is no longer used.
4. HA of the MR needs to know the MNP used in the mobile network
- According to the solution defined in [6], HA needs to know the MNP
used in the mobile network in the "static" MR scenario, in which a
routing table entry must exist in the HA of the MR. [11] defines a
solution for mobile networks, which requires a binding cache entry in
the HA, binding the MNP used on the ingress interface of the mobile
network to the COA used on the egress interface. Because information of
the MNP used in the mobile network is needed in MR's HA, it is suggested
that dynamic MNP delegation operations are executed between the MR and
its HA. Because in that case MNP delegation messages are needed between
the MR and its HA, it is suggested that dynamic MNP delegation
functionalities are implemented as a MIPv6 extension.
4.1 MIPv6 extension overview
The defined extension borrows from the Automatic IPv6 Prefix Delegation
Protocol [7] and from IPv6 Prefix Options for DHCPv6 [8] drafts. Some
of the features in those documents are embedded to the MIPv6 extension
protocol defined in this document. MR of a mobile network acts as a MNP
requestor and HA as a MNP delegator. One new ICMPv6 message and new
options inside of it (MNP Delegation-Message) are defined to be used in
the extension. New ICMPv6 codes for MNP delegation related signalling
are also defined. This means that the MR can dynamically request,
return and refresh a MNP from its HA. Also MNP lifetime updates from
the HA to the MR are supported. HA allocates the MNP(s) to the MR for a
certain period of time. The MNP can be delegated to the MR either
temporarily or permanently. In figure 1 an example can be seen of the
extension's usage. In the example MR is at a foreign domain and MR
acquires a MNP and sends a MNP Delegation-Message to its HA. HA
allocates a MNP for the MR and sends back a MNP Delegation response and
the delegated MNP. MR receives the MNP and starts advertising it on its
Pkk÷nen et al. Expires September 2003 [Page 3]
INTERNET-DRAFT MNP Delegation March 2003
local links using Router Advertisements. MR can delegate MNPs also when
it is at home. More examples of the protocol usage have been
demonstrated in chapter 5.5.
_________
(Internet )------------Home network--HA
(_______) /
| 2. code: 'MNP Delegated' / /\ 1. code: 'MNP Request'
| / /
Foreign network / /
| \/ /
( MR )-----------------------/
( | )
( | ) 3. Router Advertisement (MNP)
( | )
( MN )
----
Figure 1. MNP delegation for a MR in a foreign network.
5. Protocol
In this chapter the MIPv6 protocol extension for dynamic MNP
delegation is defined.
5.1 Operational environment
There are two entities participating in the protocol as can be seen in
figure 2. MNP delegator is MR's home agent, which can delegate MNP(s)
for the MR. MR is a MNP requestor, and requests MNP(s) from its HA. MR
can have multiple HAs i.e. MNP delegators.
__________
( Internet )------Home network--HA
(________) (MNP delegator)
|
|
|
MR
(MNP requestor)
Figure 2. Protocol entities.
5.2 Messages
There is one new ICMPv6 message defined for the MIPv6 protocol. MNP
Delegation-Message is used by the MR to query and request HA for MNP(s),
return MNP(s) and refresh the lease of MNP(s). MNP Delegation-Message
can also be used by HA to signal MR of updating operations regarding
the leased MNP(s). The same message type is used as a response to these
operations. Different type of operations and responses are distinquished
by the different ICMPv6 code types.
Pkk÷nen et al. Expires September 2003 [Page 4]
INTERNET-DRAFT MNP Delegation March 2003
5.2.1 MNP Delegation-Message
MNP Delegation-Message is used by MR to query, request, refresh and
return MNP(s). It is also used by the HA to inform MR of updating
operations.
Message format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
IP fields
Source Address
Source IPv6 address of MR or its HA
Destination Address
Destination address of MR or its HA.
Hop Limit
Set to an initial hop limit value, similarly to any other unicast
packet sent by a mobile node.
Routing Header:
A routing header of type 2 MUST be added to the message if HA is
sending a MNP Delegation-Message to the MR and MR is not at home i.e
has a binding in the HA's binding cache. Otherwise a routing header
of type 2 MUST not be used.
AH or ESP header:
IP security is not discussed in this version of the draft.
ICMP fields:
Type:
xxx for MNP Delegation-Message <To be assigned by IANA>
Code:
Pkk÷nen et al. Expires September 2003 [Page 5]
INTERNET-DRAFT MNP Delegation March 2003
MNP Delegator Query (0)
The MNP Delegator Query message is used by the MR to query MNP
delegators (HAs) and their abilities to delegate MNP(s). This
message is sent to MR's HA during the MNP Query sequence.
MNP Request (1)
The MNP Request message is used by the MR to request for MNP(s)
from its HA(s). This message is sent during the MNP Delegation
sequence.
MNP Refresh (2)
The MNP Refresh message is used by the MR to request a refresh
on the lifetimes of delegated MNP(s). This message is sent during
the MNP Refresh sequence.
MNP Return (3)
The MNP Return message is used by the MR to return delegated
MNP(s) to its HA. This message is sent during the MNP Return
sequence.
MNP Delegator (4)
A MNP Delegator message is sent by the HA during MNP Query
sequence. It is used to inform MR of MNP(s) HA is capable of
delegating.
MNP Delegated (5)
A MNP Delegated message is used by HA during MNP Delegation and
MNP Refresh sequence. It is used to inform MR of delegated and
refreshed MNP(s).
MNP Returned (6)
A MNP Returned message is sent by HA during MNP Return sequence.
It is used to inform MR of returned MNP(s).
MNP Unavailable (7)
A MNP Unavailable message is used in all the sequences to inform
of non-valid MNP(s) operations.
MNP Update (8)
A MNP Update message is used by HA to inform MR of lifetime
changes concerning the delegated MNP(s).
MNP Update-Ack (9)
Pkk÷nen et al. Expires September 2003 [Page 6]
INTERNET-DRAFT MNP Delegation March 2003
A MNP Update-Ack is used by MR to responde to MNP Update
messages sent by its HA.
Checksum
The ICMP Checksum as defined in [9].
Transaction identifier
An unique identifier used to match a MNP Delegation-Message
request to a corresponding MNP Delegation-Message response.
Reserved
This field is unused. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Options:
Destination Option:
A Home Address destination option MUST be included if MR sends a
MNP Delegation-Message and is away from home.
MNP Option:
MUST contain one MNP Option. The MNP requestor and MNP Delegator
can describe the MNP(s) by adding a MNP Option to the MNP
Delegation-Message.
5.3 Options
In this chapter the new options, which are used in the new ICMP
message, are defined.
5.3.1 MNP Option
This option is used in MNP Delegation-Message. It is used to contain
MNP information in one or more MNP Data Options.
Option format:
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 | Option length | Option body
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
Type:
0x01
Pkk÷nen et al. Expires September 2003 [Page 7]
INTERNET-DRAFT MNP Delegation March 2003
Option length:
Length of option body.
Option body:
Message body can contain up to x MNP Data Options. However it
is recommended that the IPv6 packet size is smaller the MTU for
IPv6 (1280 octets) [10] which limits the number of MNP Data
Options used in a MNP Option.
5.3.2 MNP Data Option
MNP Data Option holds MNP information related to a single MNP.
Option format:
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 | Preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Prefix length | IPv6 prefix (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Match |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
0x02
Preferred lifetime:
The recommended lifetime for the MNP in the option expressed in
seconds. A value of 0xffffffff represents infinity.
Valid lifetime:
The valid lifetime for the MNP in the option expressed in
seconds. A value of 0xffffffff represents infinity.
Prefix length:
Length for this MNP in bits.
Pkk÷nen et al. Expires September 2003 [Page 8]
INTERNET-DRAFT MNP Delegation March 2003
IPv6 prefix:
A MNP.
Match:
This field is used to indicate MNP preference of the MR during MNP
Query and MNP Delegation sequences.
Defined values:
0, indicates that MNP query/delegation is based on both MNP and its
length indicated by the values in Prefix length and IPv6 prefix
fields in the MNP Data Option.
1, indicates that MNP query/delegation is based only on MNP length
indicated by the value in Prefix length field in the MNP Data
Option.
5.4 Operation
In this chapter operation of the protocol is described.
5.4.1 MNP Query sequence
The MNP Query sequence consists of a transaction between the MR and
its HA. A transaction consists of a MNP Delegation-Message and MNP
Delegation-Message response exchange with the same transaction
identifiers. The sequence is initiated by the MR to query its HA's
capabilities to delegate MNP(s) to the MR. This sequence can be
performed multiple times with one or more HAs. After the MR has queried
the capabilities of its HAs with this sequence, MR should advance to
MNP Delegation sequence with the chosen HA to proceed with MNP
delegation.
MR functionality:
The MR might initially know the addresses of one or more of its HAs.
If the MR is at home, it learns the HA's address by receiving Router
Advertisements from its HA. If MR is away from home and does not know
any HA addresses, it SHOULD initiate Dynamic Home Agent Discovery as
defined in section 11.4.1 of [2]. After MR knows the addresses of one
or more HAs, the MNP Query sequence can be executed.
The MNP Query sequence consists of a transaction between the MR and
its HA. Transactions are initiated by the MR to query the capabilities
of MR's HA to delegate MNPs. A transaction consists of a MNP
Delegation-Message sent by the MR to its HA and a MNP Delegation-Message
response sent back to the MR by the HA. MR initiates the transaction by
sending a MNP Delegation-Message with code 'MNP Delegator Query' to one
of its HAs. The MNP Delegation-Message is constructed by the MR always
independently of its ICMPv6 code as follows:
Pkk÷nen et al. Expires September 2003 [Page 9]
INTERNET-DRAFT MNP Delegation March 2003
- IP source address field: The source address SHOULD be set to its
current Care-Of-Address if MR is away from home. If MR is at home,
its home address MUST be used.
- IP destination address field: Destination address MUST be set to HA
address. If MR is away from home, the HA to which MR has a binding
update list entry MUST be used. Otherwise the stored HA address
SHOULD be used.
- Home address destination option: MR's home address MUST be included
in a Home Address destination option, if MR is not at home.
- Transaction identifier: The Transaction identifier SHOULD be chosen
randomly to identify this transaction uniquely.
- MNP Option: A MNP Option MUST be set in the message to describe the
MNP(s) MR is interested in. One MNP Data Option inside the MNP
Option describes one MNP for delegation. The valid and preferred
lifetimes MAY be set to indicate MR's preference for MNP(s). Match
field MUST be set as described in section 5.3.2.
- Binding update list: If MR is away from home it MUST have a binding
entry in the binding cache at its HA, with which it is
communicating. This means that the HA's address MUST be present in
the binding update list of the MR.
In this case the code of the MNP Delegation-Message MUST be set to
'MNP Delegator Query'. If the MR doesn't receive a MNP
Delegation-Message response back within MNP_REQUEST_DELAY milliseconds,
the previously sent MNP Delegation-Message SHOULD be sent up to
MNP_REQUEST_MAX_RETRIES times to the same HA. When MR receives a MNP
Delegation-Message within MNP_REQUEST_DELAY milliseconds, it SHOULD
check it as follows independently of its ICMPv6 code:
- ICMPv6 type: Check that the ICMPv6 type of the received message is
MNP Delegation-Message.
- IP destination address field: If MR is at home, check that the
destination address in the IP header field is MR's home address. If
MR is not at home, check that the destination address is MR's COA.
- IP source address field: Check that the IP source address field of
the message is the same as the destination address in the
corresponding MNP Delegation-Message with the same transaction
identifier.
- Routing header type 2: If MR is not at home, the packet MUST have a
type 2 routing header with MR's home address and destination
IP header field has MR's COA.
- MNP Option: Check that a MNP Option with one or more MNP Data
Options is present in the message.
If these conditions are not met, MR MUST silently ignore the message. If
the code of the MNP Delegation-Message response is 'MNP Delegator', MR
knows that the HA is capable of delegating the MNP(s) in the MNP Option.
If the MNP in the received MNP Data Option is all zeros, HA is not
capable of delegating the wanted MNP. If MR queried for x pieces of
MNPs, the information of the MNP queries are in the corresponding places
in the reply. For example the second queried MNP information is in the
second MNP Data Option of the received MNP Option. If the code is
Pkk÷nen et al. Expires September 2003 [Page 10]
INTERNET-DRAFT MNP Delegation March 2003
'MNP Unavailable', MR knows that the HA is not capable of delegating any
of the MNPs the MR queried. The queried MNPs are present in the MNP
Option of the reply. If MR does not receive any response after
MNP_REQUEST_MAX_RETRIES attempts, the MR MAY start the MNP Query
sequence again or conclude that its HA is not capable of delegating
MNPs.
After the MNP Query sequence MR can decide to proceed to MNP
Delegation sequence based on the received MNP information in the MNP
Option or it can continue with a new MNP Query sequence. MR might
continue MNP Query sequence with its HA, because MR might not be
satisfied with the capabilities of the HA to delegate MNPs. In that case
MR MAY change the MNP descriptions in the MNP Option of the new MNP
Delegation sequence.
HA functionality:
After the HA receives a MNP Delegation-Message from a MR, HA has to
check it as follows independently of the code of the message:
- ICMPv6 type: The type of the ICMPv6 message MUST be
MNP_DELEGATION_MESSAGE.
- IP source address field: If the received message has a Home Address
destination option, the COA in binding cache of the home address
MUST be equal to the IP source address.
- IP destination address field: The destination address MUST be the
HA's IP address.
- MNP Option: Check that the MNP Delegation-Message has a MNP Option
with one or more MNP Data Options.
If these checks are not valid, HA MUST silently ignore the message.
In this case the ICMPv6 code of the received message MUST be 'MNP
Delegator Query'. HA can now inform the MR about the MNP(s) it is
capable of delegating. It SHOULD make the choice based on the
received information in the MNP Option. Each MNP Data Option SHOULD be
considered as one MNP information query. If the match field is set to
zero in the MNP Data Option, the MNP is wanted to be queried based on
MNP and its length. If the match field is set to one, MNP is wanted to
be queried only based on MNP length. HA SHOULD follow these
preferencies in the sequence, but can inform MNPs based on it own
criteria. If a MNP is not wanted to be informed to the MR based on a
MNP information query, all zeros MUST be set to the MNP field in the
MNP Data Option. If the HA is not capable of delegating any MNP(s)
queried for in the request, a MNP Delegation-Message with code
'MNP Unavailable' MUST be sent to the MR. In this case the MNP Data
Options MUST be copied from the request message. Otherwise MNP
information of the MNP(s), which HA is capable of delegating MUST be
attached to the MNP Option of a MNP Delegation-Message. The MNP Data
Options in the response MUST follow the order of the information queries
in the request. This means that nth MNP Data Option to nth MNP query
MUST be in the nth position in the MNP Option. A MNP Delegation-Message
Pkk÷nen et al. Expires September 2003 [Page 11]
INTERNET-DRAFT MNP Delegation March 2003
SHOULD be constructed and sent as follows independently of its code:
- IP source address field: HA's global IP address is set as source
address in the IP header source address field.
- IP destination address field: The corresponding MNP
Delegation-Message's source address is set as destination address in
the IP header destination address field.
- Transaction identifier: Copy the Transaction identifier from the MNP
Delegation-Message to the response's transaction identifier field.
- Routing header type 2: A type 2 routing header MUST be included with
the MR's home address if the received MNP Delegation-Message had a
Home Address destination option. The home address is received from
the Home Address destination option of the corresponding MNP
Delegation-Message.
- The match field: The match field MUST copied from the request
message from the corresponding MNP Data Options.
In this case the code 'MNP Delegator' is set as the type of the MNP
Delegation-Message. HA might receive multiple identical MNP
Delegation-Message messages, because of retransmissions at the MR. The
HA SHOULD handle and answer to these messages identically to those
received before.
5.4.2 MNP Delegation sequence
The MNP Delegation sequence can be initiated by the MR after the MNP
Query sequence or without it. It is used by the MR to delegate MNP(s)
from its HA(s). After successfully executing the sequence, one or more
MNP(s) have been delegated for the MR.
MR functionality:
The MNP Delegation sequence begins when MR sends a MNP
Delegation-Message with an ICMPv6 code of 'MNP Request' to its HA. MR
can select the HA for MNP delegation based on the MNP Query sequence.
The MNP Delegation-Message is constructed and sent as described in the
MNP Query sequence (chapter 5.4.1). The ICMPv6 code of the message is
now 'MNP Request'.
If the MR receives a MNP Delegation-Message it has to check it as
described in chapter 5.4.1 for MR functionality. If the checks are
valid, MR SHOULD proceed as follows:
- If the code of the response is set to 'MNP Delegated', MR can
consider one or more MNP(s) delegated. Those MNP Data Options which have
all zeros in the MNP field, could not be delegated. The preferred and
valid lifetimes in the MNP Data Options indicate the lifetimes for the
delegated MNP(s). MR SHOULD store delegated MNP(s) with MNP length, HA's
address and lifetimes (MNP <-> MNP length <-> HA's address <-> valid
lifetime left <-> preferred lifetime left <->). This helps when
returning or refreshing the delegated MNP.
Pkk÷nen et al. Expires September 2003 [Page 12]
INTERNET-DRAFT MNP Delegation March 2003
- If the code is set to MNP Unavailable, none of the wanted MNP(s)
were available for delegation. In this case MR MAY proceed MNP
Delegation/Query sequence with different MNP preferences.
If the MR doesn't receive a MNP Delegation-Message response back
within MNP_REQUEST_DELAY milliseconds, the previously sent MNP
Delegation-Message MAY be sent up to MNP_REQUEST_MAX_RETRIES times to
the same HA. If the MR does not receive a response to its request after
sending MNP_REQUEST_MAX_RETRIES requests, MR can conclude that the HA
in question is not capable of delegating the wanted MNPs.
HA functionality:
If HA receives a MNP Delegation-Message with code 'MNP Request' it
MUST check the request as described in chapter 5.4.1 for HA
functionality. If the checks are valid, HA can proceed as follows:
- If the wanted MNP(s) are available for delegation, HA constructs and
sends a MNP Delegation-Message as described in chapter 5.4.1 for HA
functionality except the ICMPv6 code is set to 'MNP Delegated'. A MNP
Option is added to the message based on the MNP(s) to be delegated. The
MNP Delegation occurs similarly as in the MNP Query sequence, but in
this case the MNP(s) are actually delegated instead of just informing
information about available MNPs. The HA SHOULD store the delegated
MNP(s) with the home address of the MR, MNP length and lifetimes (MNP
<-> MNP length <-> MR's home address <-> valid lifetime left <->
preferred lifetime left). This will later be helpful when refreshing or
returning related to the delegated MNP(s) occur.
- If the MR cannot delegate any MNP(s) for the MR, it MUST send a MNP
Delegation-Message back to the MR with a code 'MNP Unavailable' as
described in chapter 5.4.1 for HA functionality. The MNP Option MUST
be copied from the corresponding request.
The MNP Delegation-Message may not reach its destination and the same
message might be retransmitted to the HA. In this case the retransmitted
message MUST be handled similarly as previously received identical
messages.
5.4.3 MNP Refresh sequence
MNP Refresh sequence is initiated by the MR to refresh the lifetimes
of leased MNP(s) with finite lifetimes.
MR functionality:
When the valid or preferred lifetime of a delegated MNP diminishes
under a certain threshold, its lease SHOULD be renewed with the MNP
Refresh sequence. The recommended time for MNP refreshing is not
specified here. MR sets the MNP(s) to be refreshed in a MNP Option and
sends a MNP Delegation-Message to the HA from which the MNP(s) were
delegated from. The HA's address corresponding to the leased MNP should
have been previously stored with the delegated MNP, from which it can
Pkk÷nen et al. Expires September 2003 [Page 13]
INTERNET-DRAFT MNP Delegation March 2003
be received for refreshing. The wanted lifetimes for the new MNP
delegation can be set according to the MR's preference. The MNP Refresh
sequence begins when the MNP Delegation-Message message is constructed
and sent as described in chapter 5.4.1 for MR functionality. The ICMPv6
code of the message is now 'MNP Refresh'.
If the MR receives a MNP Delegation-Message it has to check it as
described in chapter 5.4.1 and in addition to that proceed as follows:
- If the code of the response is set to 'MNP Delegated', it can
consider the MNP(s) refreshed. The preferred and valid lifetimes in the
MNP Data Options indicate the lifetimes for the delegated MNP(s). If a
MNP Data Option contains all zeros in the MNP field, the corresponding
MNP can be considered as not refreshed.
- If the code is set to MNP Unavailable, none of the MNP(s) could be
refreshed. In this case the old lifetimes stay valid for the MNP(s).
If the MR doesn't receive a MNP Delegation-Message back within
MNP_REQUEST_DELAY milliseconds, the previously sent MNP
Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to
the same HA. If the MR does not receive a response to its request after
sending MNP_REQUEST_MAX_RETRIES requests, it might be because the
corresponding HA is down for some reason. In this case the MR MAY return
to MNP Refresh sequence after some unspecified amount of time.
HA functionality:
If HA receives a MNP Delegation-Message with code 'MNP Refresh' it
MUST check the request as described in chapter 5.4.1 for HA
functionality. If the checks are valid, HA can proceed as follows:
- If the HA is able to refresh lifetimes of one or more MNPs, HA
constructs and sends a MNP Delegation-Message as described in chapter
5.4.1 for HA functionality, except the ICMPv6 code is set to
'MNP Delegated'. The lifetimes of the refreshed MNP(s) MAY be chosen by
the delegating HA independently of the requested lifetimes in the MNP.
The requested lifetimes SHOULD however be used as guidance when
refreshing the MNP(s). All the MNP(s) which can be refreshed by the HA,
MUST be included in a MNP Option, which is sent back to the requesting
MR in a MNP Delegation-Message. If a MNP cannot be refreshed, all zeros
MUST be set to the MNP field in the MNP Data Option.
- If the MR cannot refresh any MNP(s), it MUST send a MNP
Delegation-Message back to the MR with a code 'MNP Unavailable'. The
MNP Option MUST be copied from the corresponding request.
The MNP Delegation-Message message may not reach its destination and
the same message might be retransmitted to the HA. In this case the
retransmitted message MUST be handled similarly as previously received
messages.
5.4.4 MNP Return sequence
Pkk÷nen et al. Expires September 2003 [Page 14]
INTERNET-DRAFT MNP Delegation March 2003
MNP Return sequence is initiated by the MR when the MR no longer needs
the previously delegated MNP(s).
MR functionality:
When MR no longer needs the leased MNP(s) for some reason, it SHOULD
return them to the HA, which delegated the MNP(s). This is executed with
the MNP Return sequence. The information related to the MNP(s) to be
returned MUST be included inside a MNP Option, which is placed inside
the MNP Delegation-Message. The MNP Return sequence begins when the MNP
Delegation-Message is constructed and sent as described in chapter 5.4.1
for MR functionality. The ICMPv6 code of the message is now set to
'MNP Return'. HA's address should have been stored during MNP
Delegation, and is used now as a destination address.
If the MR receives a MNP Delegation-Message it has to check it as
described in chapter 5.4.1 for MR functionality and if the checks are
valid, proceed as follows:
- If the ICMPv6 code of the response is set to 'MNP Returned', MR can
consider those MNP(s) returned, which have zero lifetimes in the MNP
Option. If a MNP Data Option contains all zeros in the MNP field,
the corresponding MNP can be considered as not returned.
- If the ICMPv6 code is set to MNP Unavailable, none of the MNP(s) in
the MNP Option were returned. In this case the old lifetimes stay
valid for the MNPs.
If the MR doesn't receive a MNP Delegation-Message back within
MNP_REQUEST_DELAY milliseconds, the previously sent MNP
Delegation-Message SHOULD be sent up to MNP_REQUEST_MAX_RETRIES times to
the same HA. If the MR does not receive a response to its request after
sending MNP_REQUEST_MAX_RETRIES requests, it might be because the
corresponding HA is down for some reason. In this case the MR MAY return
to MNP Return sequence after some unspecified amount of time.
HA functionality:
If HA receives a MNP Request with ICMPv6 code 'MNP Return', it MUST
check the request as described in section 5.4.1 for HA functionality.
If the checks are valid, the HA can proceed as follows:
- HA has to determine if the returned MNP(s) have been delegated by the
HA to the requesting MR. The MNP(s) which have not been delegated by
the HA, MUST have all zeros in the MNP field in the MNP Data Option.
The MNP(s) which have been delegated by the HA and can be returned,
MUST be included in the MNP Data Options of the response. The
lifetimes of those MNP(s) MUST be set to zero to indicate that
they are not valid anymore. HA constructs a MNP Delegation-Message as
described in chapter 5.4.1 for HA functionality except the ICMPv6 code
is set to 'MNP Returned'.
- If none of the MNP(s) belong to the HA, a MNP Delegation-Message with
Pkk÷nen et al. Expires September 2003 [Page 15]
INTERNET-DRAFT MNP Delegation March 2003
the ICMPv6 code of 'MNP Unavailable' has to be returned to the
requestor as described in chapter 5.4.1 for HA functionality. The MNP
Option MUST be copied from the corresponding request.
The MNP Delegation-Message message may not reach its destination and
the same message might be retransmitted to the HA. In this case the
retransmitted message MUST be handled similarly as previously received
identical messages.
5.4.5 MNP Update sequence
MNP Update sequence is initiated by the HA when the valid or preferred
lifetimes of a delegated MNP are changed by the HA. With this sequence
those lifetime changes are informed to the MR, which originally
delegated the MNP. The MR might detect that the lifetimes of a delegated
MNP have been changed to zero by its HA. This means that the MNP cannot
be used anymore, and a new MNP should be delegated from the HA with the
MNP Query/Delegation sequences.
HA functionality:
When valid or preferred lifetimes on one or more delegated MNPs are
changed by the MR, that information is informed to the MR by sending a
MNP Delegation-Message with ICMPv6 code 'MNP Update' to the MR as
described in chapter 5.4.1 for HA functionality with the following
changes to all message handling except IP source address field:
- MNP Option: When updating MNP(s), a MNP Option MUST be added to the
message to indicate the MNP(s) updating operation is concerned with.
The new valid and preferred lifetimes are set to the MNP Data
Options.
- IP destination address field: The destination address in the IP
header MUST be set to the MR's Home Address if that Home Address has
no entry in the binding cache. This means that the MR is at home.
MR's home address should have been saved during the MNP Delegation
sequence with the MNP. Otherwise the COA from the binding cache MUST
be used.
- Transaction identifier: A new random transaction identifier MUST be
used in the transaction identifier field.
- Routing header type 2: A type 2 routing header MUST be included with
the MR's home address, if the MR's home address has a binding cache
entry.
- The match field: The match field MUST set to zero in all MNP Data
Options to indicate a match based on both MNP and its length.
If HA doesn't receive a MNP Delegation-Message message within
MNP_REQUEST_DELAY milliseconds, HA SHOULD retransmit the same message.
If no response is received after MNP_REQUEST_MAX_RETRIES
retransmissions, HA MAY proceed with its own preference. If the MR
doesn't respond for any reason, HA MAY initiate MNP Updating sequence
again after some time or it might stop sending messages to the MR.
However, the HA can only be sure that MR has received the updating MNP
Delegation-Message, when HA receives a MNP Delegation-Message with
Pkk÷nen et al. Expires September 2003 [Page 16]
INTERNET-DRAFT MNP Delegation March 2003
ICMPv6 code of 'MNP Update Ack'.
When HA receives a MNP Delegation-Message with code 'MNP Update-Ack'
it SHOULD check it as described in chapter 5.4.1 for HA functionality
with the following additional check:
- IP source address field: Check that the IP source address field of
the message is the same as the destination address in the
corresponding MNP Delegation-Message request with the same
transaction identifier.
If the checks are valid, it SHOULD proceed as follows:
- The MNP(s) in the MNP Data Options of the MNP Option indicate the
MNP(s), which MR has updated. The HA SHOULD now update the
lifetimes on its local storage. If a MNP Data Option contains all
zeros in the MNP field, the corresponding MNP can be considered as
not updated.
- If the code is set to MNP Unavailable, none of the MNP(s) in the MNP
Option were updated. In this case the old lifetimes stay valid for
the MNPs.
MR functionality:
When MR receives a MNP Delegation-Message with ICMPv6 code
'MNP Update', it MUST perform checks on all items except IP source
address field as described in chapter 5.4.1 for MR functionality with
the following additional checks:
- IP source address field: Check that the IP source address field of
the message is the HA's address from which MR originally delegated
the MNP.
If the checks are not valid, MR MUST silently ignore the message.
Otherwise
- Those MNP(s) which have zero lifetimes, are going to be expired and
SHOULD not be used anymore after this message is received. Those
MNP(s) which have non-zero lifetimes, can be used as before, and
the lifetimes of those MNP(s) SHOULD be updated on local storage.
Based on the received update message a MNP Delegation-Message MUST be
constructed on items concerning IP source address field, Home Address
destination option and binding update list as described in chapter 5.4.1
for MR functionality. In addition the other items are constructed as
follows:
- IP destination address field: Destination address MUST be copied
from the destination address field of the corresponding update
message.
- Transaction identifier: The Transaction identifier MUST be copied
Pkk÷nen et al. Expires September 2003 [Page 17]
INTERNET-DRAFT MNP Delegation March 2003
from the corresponding update message.
- The match field: Match field MUST be copied from the corresponding
update message's MNP Data Options.
- MNP Option and ICMPv6 code: MR MUST check that the MNP(s) in the
update have before been delegated to the MR. Those MNP(s) which
have been delegated before MUST be copied from the update message
to MNP Data Option of the message. Those MNP(s) which cannot be
updated, MUST have all zeros in the MNP field of the MNP Data
Option. If one or more of the updated MNP(s) were updated
successfully, ICMPv6 code of the message is set to
'MNP Update Ack'. If none of the MNP(s) could be updated
successfully, the MNP Data Options MUST be copied from the update
message to the response, and the ICMPv6 code MUST be set to 'MNP
Unavailable'
The MNP Delegation-Message message may not reach its destination and
the same MNP Delegation-Message message might be retransmitted to the
MR. In this case the retransmitted message MUST be handled similarly as
previously received identical messages.
5.5 Examples
In this section a transaction related to both MNP Query and MNP
Delegation sequences are depicted. In the first case MR is at home and
in the second case MR is at a foreign domain. Also a transaction related
to MNP Updating sequence is presented as defined in chapter 5.4.5.
5.5.1 MNP Query sequence
MR at home:
_____________ ___________
( ) / \
( Internet )------|Home domain |---HA
(_____________) \__________/
|
MR
In this example the MR is at home and proceeds with MNP Query with its
HA. MR wants to be delegated an arbitrary MNP of length 48 and a certain
MNP (4ffe:1:1:1/64). HA responds back to the MR by informing that a MNP
of 48 can be delegated from the HA and 4ffe:1:1:1/64 MNP is not
available for delegation.
Message flows:
MR HA
----------------------------------------------->
Pkk÷nen et al. Expires September 2003 [Page 18]
INTERNET-DRAFT MNP Delegation March 2003
MNP Delegation-Message
IP fields:
[
Source address: MR's home address
Destination address: HA address
]
ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Delegator Query
Transaction ID: 23456
Reserved: 0
MNP Option:
[
Type=0x01
Option length=2*sizeof(MNP Data Option)
MNP Data Option
[
Preferred lifetime: 3600
Valid lifetime: 3600
Prefix length: 48
IPv6 Prefix: 0x0
Match: 1
]
MNP Data Option
[
Preferred lifetime: 3600
Valid lifetime: 3600
Prefix length: 64
IPv6 Prefix: 4ffe:1:1:1
Match: 0
]
]
]
<-----------------------------------------------
MNP Delegation-Message
IP fields:
[
Source address: HA's address
Destination address: MR's home address
]
ICMP fields:
[
Type: MNP Delegation-Message
Pkk÷nen et al. Expires September 2003 [Page 19]
INTERNET-DRAFT MNP Delegation March 2003
Code: MNP Delegator
Transaction ID: 23456
Reserved: 0
MNP Option:
[
Type=0x01
Option length=2*sizeof(MNP Data Option)
MNP Data Option
[
Preferred lifetime: 3600
Valid lifetime: 3600
Prefix length: 48
IPv6 Prefix: 3ffe:2222:2222::0
Match: 1
]
MNP Data Option
[
Preferred lifetime: 0
Valid lifetime: 0
Prefix length: 64
IPv6 Prefix: 0::0
Match: 0
]
]
]
5.5.2 MNP Delegation Sequence
MR not at home:
_____________ __________
( ) / \
( Internet )------|Home domain|---HA
(_____________) \_________/
|
___|_______
| |
| Foreign |
| domain |
\________/
|
|
MR
In this example the MR is at a foreign domain and proceeds with MNP
delegation with its HA. MR wants to be delegated a certain MNP of length
48. HA responds by delegating the MNP for the MR.
Message flows:
Pkk÷nen et al. Expires September 2003 [Page 20]
INTERNET-DRAFT MNP Delegation March 2003
MR HA
----------------------------------------------->
MNP Delegation-Message
IP fields:
[
Source address: MR's COA
Destination address: HA's address
]
Home address destination option
[
Home Address=MR's home address
]
ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Request
Transaction ID: 67890
Reserved: 0
MNP Option:
[
Type=0x01
Option length=1*sizeof(MNP Data Option)
MNP Data Option
[
Preferred lifetime: 3600
Valid lifetime: 3600
Prefix length: 48
IPv6 Prefix: 3ffe:2222:2222::0
Match: 0
]
]
]
<-----------------------------------------------
MNP Delegation-Message
IP fields:
[
Source address: HA's address
Destination address: MR's COA
]
Type 2 Routing Header
[
Home Address=MR's Home Address
Pkk÷nen et al. Expires September 2003 [Page 21]
INTERNET-DRAFT MNP Delegation March 2003
]
ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Delegated
Transaction ID: 67890
Reserved: 0
MNP Option:
[
Type=0x01
Option length=1*sizeof(MNP Data Option)
MNP Data Option
[
Preferred lifetime: 3600
Valid lifetime: 3600
Prefix length: 48
IPv6 Prefix: 3ffe:2222:2222::0
Match: 0
]
]
]
5.5.3 MNP Updating sequence
MR not at home:
_____________ __________
( ) / \
( Internet )------|Home domain|---HA
(_____________) \_________/
|
___|_______
| |
| Foreign |
| domain |
\________/
|
|
MR
In this example the MR is at a foreign domain and HA proceeds with
updating the lifetimes of the previously delegated MNP to zero. After
this sequence the updated MNP is no longer valid in the MR, and MR has
to delegate a new MNP by running the MNP Query and MNP Delegation
sequences.
Message flows:
HA MR
Pkk÷nen et al. Expires September 2003 [Page 22]
INTERNET-DRAFT MNP Delegation March 2003
----------------------------------------------->
MNP Delegation Message:
IP fields:
[
Source address: HA address
Destination address: MR's COA
]
Type 2 Routing header
[
Home Address=MR's home address
]
ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Update
Transaction ID: 948738
Reserved: 0
MNP Option:
[
Type=0x01
Option length=1*sizeof(MNP Data Option)
MNP Data Option
[
Preferred lifetime: 0
Valid lifetime: 0
Prefix length: 48
IPv6 Prefix: 3ffe:2222:2222::0
Match: 0
]
]
]
HA MR
<-----------------------------------------------
MNP Delegation-Message
IP fields:
[
Source address: MR's COA
Destination address: HA's address
]
Home address destination option
[
Home Address=MR's home address
Pkk÷nen et al. Expires September 2003 [Page 23]
INTERNET-DRAFT MNP Delegation March 2003
]
ICMP fields:
[
Type: MNP Delegation-Message
Code: MNP Update-Ack
Transaction ID: 948738
Reserved: 0
MNP Option:
[
Type=0x01
Option length=1*sizeof(MNP Data Option)
MNP Data Option
[
Preferred lifetime: 0
Valid lifetime: 0
Prefix length: 48
IPv6 Prefix: 3ffe:2222:2222::0
Match: 0
]
]
]
6. Constants
MNP_REQUEST_DELAY=500
MNP_REQUEST_MAX_RETRIES=3
7. Security issues
Security issues of this MIPv6 extension are not considered in the
draft. These issues must be considered in the next version of the draft.
Acknowledgements
The author would like to thank the following persons on the NEMO mailing
list for feedback in an alphabetical order:
Erik Nordmark
Alexandru Petrescu
Mattias Pettersson
References
[1] S. Bradner "Key words for use in RFCs to Indicate Requirement
Levels" BCP 14, RFC 2119, Internet Engineering Task Force, March
1997.
[2] D. B. Johnson, C. E. Perkins, J. Arkko "Mobility Support in IPv6"
(draft-ietf-mobile-ipv6-21), Internet Draft, Internet Engineering
Task Force, Feb 2003.
Pkk÷nen et al. Expires September 2003 [Page 24]
INTERNET-DRAFT MNP Delegation March 2003
[3] T. Ernst, H. Lach "Network Mobility Support Terminology" (draft-
ernst-nemo-terminology-01), Internet Draft, Internet Engineering
Task Force, Nov 2002.
[4] NEtwork MObility working group website URL: http://www.nal.motlabs.
com/nemo.
[5] M. Crawford "Router Renumbering for IPv6" RFC 2894, Internet
Engineering Task Force, Aug 2000.
[6] T. J. Kniveton, J. T. Malinen, V. Devarapalli, C. E. Perkins "Mobile
Router Tunneling Protocol" (draft-kniveton-mobrtr-03) Internet
Draft, Internet Engineering Task Force, Nov 2002.
[7] B. Haberman, J. Martin "Automatic Prefix Delegation Protocol for
Internet Protocol Version 6 (IPv6)"
(draft-haberman-ipngwg-auto-prefix-02), Internet Draft, Internet
Engineering Task Force, Feb 2002.
[8] O. Troan, R. Droms "IPv6 Prefix Options for DHCPv6"
(draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03), Internet Draft,
Internet Engineering Task Force, March, 2003.
[9] A. Conta, S. Deering "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463,
Internet Engineering Task Force, Dec 1998.
[10] S. Deering, R. Hinden "Internet Protocol, Version 6 (IPv6)
Specification" RFC 2460, Dec 1998.
[11] Wakikawa R. K. Uehara, K. Mitsuya, T. Ernst "Basic Metwork Mobility
Support" (draft-wakikawa-nemo-basic-00), Internet Draft, Internet
Engineering Task Force, Feb, 2003.
Authors' addresses
Pekka Pkk÷nen
VTT Electronics
Kaitovyl 1
90571 Oulu
Finland
email: pekka.paakkonen@vtt.fi
Juhani Latvakoski
VTT Electronics
Kaitovyl 1
90571 Oulu
Finland
email: juhani.latvakoski@vtt.fi
Pkk÷nen et al. Expires September 2003 [Page 25]
INTERNET-DRAFT MNP Delegation March 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 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.
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/