[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.129b, available from https://tools.ietf.org/tools/rfcmarkup/