[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
No Working Group as of yet
Internet-Draft
Expires: 31st August 2007
A. Petrescu
C. Janneteau
Motorola
February 26th, 2007
The NANO Draft
(Scene Scenario for Mobile Routers and MNP in RA)
draft-petrescu-manemo-nano-00.txt
Status of this Nano
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on August 31st, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Abstract
This short NANO draft proposes scenarios for using Mobile Routers
at fixed scenes. The routers connect by their egress interfaces
and need to allow their Local Fixed Nodes to communicate directly.
What if the Mobile Network Prefixes are stored in special Router
Advertisements sent by each Mobile Router on their egress
interface. What are the issues and can it work.
Petrescu, et al. Expires August 2007 [Page i]
Internet-Draft The NANO Draft February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Fixed Scene Scenario . . . . . . . . . . . . . . . . . . . . . 3
4. Mobile Network Prefixes in Router Advertisements . . . . . . . 3
4.1 Message Exchange . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Message Formats . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Problematic Issues . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 9
1. Introduction
The NANO draft proposes the fixed scene scenario for using Mobile
Routers. The routers connect their egress interfaces and need to
allow their Local Fixed Nodes to communicate directly. The egress
interfaces form a single IP subnet, and the link-layer is assured
for instance by technologies like IEEE 802.11 ad-hoc mode or IEEE
802.11s mesh or any other mesh-capable link-layer technology.
It is assumed in this fixed scene scenario that none of the Home
Agents of any of the Mobile Routers is reachable (for instance due
to lack of connectivity to the Internet). In this case
communication between the LFNs of different moving networks is
impossible, since the NEMOv6 tunnel between the Mobile Router and
the Home Agent can not be established.
This draft proposes a mechanism for allowing two Mobile Routers at
a fixed scene to exchange prefix information for allowing
forwarding between Local Fixed Nodes of different moving networks.
A Mobile Router sends on its egress interface special Router
Advertisements containing Mobile Network Prefixes, lifetimes and
the link-local address at which these prefixes are reachable.
The draft discusses several problematic issues with this mechanism:
risk of propagating topologically incorrect addresses, differences
of intent with rfc4191 and with rfc3963. It also hints at the
potential assignments needed from IANA and potentially use Secure
Neighbour Discovery SeND.
2. Terminology
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 [RFC2119].
Petrescu, et al. Expires August 2007 [Page 1]
Internet-Draft The NANO Draft February 2007
Terminology for network mobility support is defined in [NEMOTERM].
In addition, this document defines the following terms:
NEMOv6 - Network Mobility for IPv6, NEMOv6 RFC is [RFC3963], and NEMO
Working Group.
Mobile Router (MR) - a Mobile Router
Mobile Network Prefix (MNP) - the Mobile Network Prefix is
topologically correct on the ingress interface of a Mobile Router.
Egress interface of MR - the interface sending the special Router
Advertisements to other egress interface of other Mobile Routers
(by this draft's recommendation), connected at the fixed scene.
The egress interface of a Mobile Router defined in [RFC3963].
Ingress interface of MR - the interface towards the Local Fixed
Nodes in the moving network and on which the Mobile Network Prefix
(MNP) is topologically correct.
NANO - Network Addresses for Network Nodes, name invented for
distinguishing the method of using MNPs in RA at a fixed scene, in
the MANEMO space (and for abbreviating the length of this draft).
3. Scenarios
3.1 Scene Scenario
The Fixed Scene scenario comprises a set of Mobile Routers that are
connected together through their egress interfaces. The Home
Agents are not reachable.
The following scenarios are out of scope currently at a Fixed
Scene: nested moving networks, Visiting Mobile Routers, Visiting
Mobile Hosts, egress interface connected to another MR's ingress
interface, spanning tree construction and maintenance, loop
avoidance in routes, Mobile Routers connected to the Internet
reaching their Home Agents. For discussion of these scenarios see
[MANEMOPS], [NEMOROPS], and [TD].
We consider a number of vehicles each equipped of a Mobile Router
implementing the NEMOv6 protocol [RFC3963]. Within each vehicle, in
addition to the Mobile Router, there is a number of IP-addressable
computer equipment (Local Fixed Nodes - LFNs), all being connected
together, and to the respective Mobile Router - thus forming a
moving network. All computers in one vehicle are fixed with
respect to one another. Only the Mobile Router runs a mobility
management protocol (NEMOv6).
Petrescu, et al. Expires August 2007 [Page 2]
Internet-Draft The NANO Draft February 2007
Vehicle 1 Vehicle 2
egress| egress|
---- ---- ---- ---- ---- ----
| MR | |LFN | |LFN | | MR | |LFN | |LFN |
---- ---- ---- ---- ---- ----
ingress| | Ether | ingress| | Ether |
--------------------- ---------------------
2001:1::/24 2001:2::/24
Moving Networks in Vehicles at a Fixed Scene
The vehicles arrive at a certain scene and remain fixed for a time
necessary to resolve the scene issues. The timespan can range from
a few hours at the simplest scenes to several hours but no longer
than a few days at most complex scenes.
Different Mobile Network Prefixes (MNPs) are assigned to each
vehicle, prior to arriving at the scene, and they can differ up to
the first three bytes of an IPv6 address.
During the time the Scene lasts, all LFNs need to be able to
communicate with each other - exchange IP messages.
3.2 Personal Mobile Routers and Personal Area Networks (PMRs and PANs)
A similar use scenario is two Personal Area Networks each composed
of a mobile phone (Personal Mobile Router) and a wifi photography
camera (Local Fixed Node), in an area where no cell network is
available.
4. Mobile Network Prefixes in Router Advertisements
It is proposed by this NANO draft to use a special kind of prefixes
in the Router Advertisements. MR sends RA on its egress interface.
A receiving MR installs the pair MNP-LL in its forwarding
information base (routing table, destination cache, tbd). MR
informs the other MRs before leaving the Scene.
4.0 Conceptual Data Structure
Each Mobile Router maintains a MANEMO forwarding information
structure that contains entries of the form:
-Mobile Network Prefix
-Gateway address
-lifetime
-name of outgoing interface
-optionally link-layer address of Gateway
This structure is maintained at the reception of the special Router
Advertisement and when timers expire. This structure can be
implemented as part of the Destination Cache, Binding Cache,
Routing Table or Forwarding Information Base.
Petrescu, et al. Expires August 2007 [Page 3]
Internet-Draft The NANO Draft February 2007
4.1 Message Exchange
The mechanism is overviewed as follows:
- all Mobile Routers at the fixed Scene connect their egress
interface with a wireless MAC protocol, for example 802.11
MAC. And then:
MR1 MR2 MR3
| | |
| MLD REPORT (LL1) | |
|----------------->|----------------->|multicast
| |MLD REPORT (LL3) |
|<-----------------|<-----------------|
| MLD|REPORT (LL2) |
|<-----------------|----------------->|
| | |
| Special RA | |
|----------------->|----------------->|
| (MNP1-LL1) | |
| | Special RA |
|<-----------------|<-----------------|
| | (MNP3-LL3) |
| | |
| Special|RA |
|<-----------------|----------------->|
| (MNP2-LL2) |
- Following link-layer successful connectivity, each Mobile
Router joins the all-routers multicast address on the egress
interface (typically using a link-local address, pictured as
LL1). If the all-routers multicast address can not be used for
this goal then maybe a new address 'all-manemo-routers' should
be defined.
- Each Mobile Router multicasts special RAs on the egress
interface, containing the Mobile Network Prefix that is
assigned to its moving network.
- When receiving the special RA from another MR, a certain MR
parses the packet for the link-local address of the sending MR,
for the MNP sent by that MR and lifetime. It then installs the
corresponding entry into the manemo forwarding information
structure.
- Before leaving the Fixed Scene, a Mobile Router sends another
special RA to all routers this time informing them the
MNP-linklocaladdress is no longer present at the scene
(lifetime 0 as per [RFC4191]), so the other routers delete the
corresponding route. It could also courteously multicast a MLD
REPORT to leave the all-routers multicast group, if necessary.
Petrescu, et al. Expires August 2007 [Page 4]
Internet-Draft The NANO Draft February 2007
- Operation of the Mobile Router when forwarding packets (after
installation of the MNP-ll route) is similar to that of any
router: for each packet not addressed to itself, longest-prefix
match the destination address of the packet to an entry in the
table, select the 'gateway' address, solicit that neighbour's
MAC address and put the received MAC address in the link-layer
dst address then send it.
With this mechanism, all LFNs at the fixed Scene are capable to
exchange IP messages, routed by two Mobile Routers each time. It
is out of the scope of this document the method by which LFNs can
learn the IP addresses of their correspondents, but hardcoded or
DNS resolution could be used.
For faster discovery of the Mobile NEtwork Prefixes of the other
Mobile Routers, a certain Mobile Router can send a special Router
Solicitation right after joining the scene.
It may be necessary that the Mobile Routers need to communicate
with their Home Addresses. In this case the special Router
Advertisements should contains several prefixes, one for the MNP
and one for the MR's Home Address. A MR's Home Address can be
encoded as a Mobile Network Prefix with length 128 in the special
RA.
4.2 Packet Formats - special Router Advertisement
Router Advertisement is a message format defined in [RFC2461bis] as
an ICMPv6 message. The document [RAOPTS] proposes an option for RA
extensibility: NDP Flags Expansion option. We reserve bit 16 for
Mobile Network Prefixes.
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 | Length |M| Bit fields available ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'M' - Mobile Network Prefix present. Set to 1 if this Router
Advertisement contains a Mobile Network Prefix.
If the NDP Flags Expansion Option contais the flag M and it is set
to 1, then the Router Advertisement MUST contain a Route Information
Option [RFC4191] followed optionally by a Source-Link Layer Address
Option [RFC2461bis]. (If this SLLAO option is used it avoids the necessity
of doing NS/NA exchange for the link-local address of the Gateway
entry in the manemo forwarding information structure.)
Petrescu, et al. Expires August 2007 [Page 5]
Internet-Draft The NANO Draft February 2007
A complete diagram of the Router Advertisement for this Scene is
presented in the figure below:
Base Header (2460)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RA (4191)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NDP Expansion Flags (draft-haberman)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |M| Bit fields available ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... for assignment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Information Option (4191)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SLLAO (2461bis)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Petrescu, et al. Expires August 2007 [Page 6]
Internet-Draft The NANO Draft February 2007
Source Address:
IPv6 Link Layer Address of sending MR. To be
installed as the Gateway address in the manemo
forwarding information structure.
Destination Address:
IPv6 all-routers multicast address with
link-scope.
Prf:
Preference, value 0x09; this route should not be
preferred over other default routes, far from
that.
Prefix (in Router Information Option):
The Mobile Network Prefix of this Mobile Router.
Link-Layer Address (optional):
Link-layer address of the egress interface of the
MR. The receiving MR can use this address for
sending packets to the MR that advertises a
certain MNP.
A Mobile Router MUST not include Prefix Information Options
([RFC2461bis]) into the special Router Advertisements so that the
receiving Mobile Routers don't auto-configure addresses based on
these prefixes ([RFC2462bis]).
A Mobile Router MUST NOT auto-configure an address derived from the
Mobile Network Prefix found within a received special Router
Advertisement.
4.3 Problematic Issues
The mechanism of using Mobile Network Prefixes in special Router
Advertisements for a static Scene has not one problematic issue,
but several. Here's a short list:
- in general, prefixes advertised in Router Advertisements are not
destined to be assigned in routing tables by other routers. It
may lead to propagating routes in a completely undesired manner,
and to routing incoherencies. Only routing protocols, DHCP and
NEMO are current methods for transmitting prefixes and inserting
in routing tables.
- [RFC4191] provides a potential solving issue, by allowing prefixes
sent by a router to be installed in a host's routing table.
However, the Mobile Router is more of a router than a host (even
though [RFC3963] NEMOv6 requires the MR to behave more like a host
on the egress interface).
- [RFC3963] requires the MR to act as a host on its egress interface
and to not send Router Advertisements on that interface.
Petrescu, et al. Expires August 2007 [Page 6]
Internet-Draft The NANO Draft February 2007
It is probably possible to solve all these issues. It is needed to
develop requirements for this kind of mechanism to work and to avoid
create routing incoherencies, especially if connecting to the
Internet. Do not advertise nor propagate topologically incorrect
addresses nor prefixes into the Internet.
5. Security Considerations
It is of utmost importance that the Mobile Routers exchange the
special Router Advertisements securely.
SeND [RFC3971] permits to bind an address to a public key. But not a
prefix. This may involve concepts of the prefix-ownership problem
space.
It is necessary to build a threat model for this scenario and
mechanism, analyze the security tools offered by SeND and identify
the potential risks and their mitigation.
6. IANA Considerations
IANA not to assign any type for this draft. But for [RAOPTS] yes, see
that draft.
It may be necessary to request assignment of a new multicast address
with link-local scope: "all-manemo-routers".
7. Acknowledgements
The authors would like to thank all people who contributed
stimulating discussion on the manemo@mobileip.jp list during
November 2006 to February 2007: Pascal Thubert, Ryuji Wakikawa, Jim
Bound, Jari Arkko, Roberto Baldessari, Ben McCarthy, Teco Boot,
Nicolas Chevrollier, Jean Lorchat, Fred Templin, Carlos Jesus
Bernardos Cano, Thierry Ernst, Bryan McLaughlin, Theo De Jongh,
Thomas Heide Clausen, Lim Hyung Jin, David Binet, Samita
Chakrabarti, Shubhranshu, Richard Bernhardt, Martin Dunmore,
Emmanuel Baccelli.
The authors would like to acknowledge a number of co-workers who
strongly supported work in this area a few years ago. Their names
will appear when deemed necessary.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
Petrescu, et al. Expires August 2007 [Page 7]
Internet-Draft The NANO Draft February 2007
[RFC2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC4191] Draves, R., Thaler, D., "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC3971] Arkko, J. Kempf, J., Zill, B., Nikander, P., "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
8.2. Informative References
[NEMOTERM] Ernst, T., Lach, H-Y., "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-06.txt, work in
progress, November 2006.
[MANEMOPS] Wakikawa, R., Thubert, P., Boot, T., Bound, J.,
McCarthy, B., "MANEMO Problem Statement", IETF Internet
Draft, draft-wakikawa-manemo-problem-statement-00.txt,
work in progress, February 2007.
[NEMOROPS] Ng, C., Thubert, P., Watari, M., Zhao, F., "Network
Mobility Route Optimization Problem Statement", IETF
Internet Draft,
draft-ietf-nemo-ro-problem-statement-03.txt, work in
progress, September 2006.
[TD] Thubert, P., Bontoux, C., Montavont, N., "Nested Nemo Tree
Discovery", IETf Internet Draft,
draft-thubert-tree-discovery-04.txt, work in progress,
November 2006.
[RAOPTS] B. Haberman, B., Hinden, R., "IPv6 Router Advertisement
Flags Option", IETF Internet Draft, Work in Progress,
draft-haberman-ipv6-ra-flags-option-00.txt, July 2006.
[RFC2461bis] Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP verssion 6 (IPv6)", IETF
Internet Draft, Work in Progress, January 2007.
[RFC2462bis] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", IETF Internet Draft, Work
in Progress, draft-ietf-ipv6-rfc2462bis-08.txt, May
2005.
9. Changelog
Initial version 00
Petrescu, et al. Expires August 2007 [Page 8]
Internet-Draft The NANO Draft February 2007
Authors' Addresses
Alexandru Petrescu
Motorola
Parc les Algorithmes Saint Aubin
Gif-sur-Yvette 91193
France
Email: Alexandru.Petrescu@motorola.com
Christophe Janneteau
Motorola
Parc les Algorithmes Saint Aubin
Gif-sur-Yvette 91193
France
Email: Christophe.Janneteau@motorola.com
Intellectual Property Statement
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.
Disclaimer of Validity
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 IETF TRUST 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 OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Petrescu, et al. Expires August 2007 [Page 9]
Internet-Draft The NANO Draft February 2007
Copyright Statement
Copyright (C) The IETF Trust (2007). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Petrescu, et al. Expires August 2007 [Page 10]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/