Internet DRAFT - draft-wakikawa-nemo-fixed-access-network

draft-wakikawa-nemo-fixed-access-network






MEXT Working Group                                           R. Wakikawa
Internet-Draft                                                Toyota ITC
Intended status: Informational                               S. Miyakawa
Expires: January 5, 2009                  NTT Communications Corporation
                                                            July 4, 2008


              NEMO Basic Support for Fixed Access Networks
            draft-wakikawa-nemo-fixed-access-network-00.txt

Status of this Memo

   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 January 5, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).













Wakikawa & Miyakawa      Expires January 5, 2009                [Page 1]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


Abstract

   This document describes the usage of Network Mobility (NEMO) for the
   commercial ISPs.  NEMO can be a mechanism to provide IP subscription.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  System Design and Concept  . . . . . . . . . . . . . . . . . .  4
     2.1.  Concept  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  The Advantages of NEMO technology for ISP  . . . . . . . .  6

   3.  Technical Consideration  . . . . . . . . . . . . . . . . . . .  9
     3.1.  Expected Basic Technology  . . . . . . . . . . . . . . . .  9
     3.2.  Security and AAA . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Route Optimization Support . . . . . . . . . . . . . . . . 10
     3.4.  Site Multihoming Support . . . . . . . . . . . . . . . . . 12

   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 13

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   Appendix A.  References  . . . . . . . . . . . . . . . . . . . . . 14
     A.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     A.2.  Informative References . . . . . . . . . . . . . . . . . . 14

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 17





















Wakikawa & Miyakawa      Expires January 5, 2009                [Page 2]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


1.  Introduction

   Commercial Internet Service Provider (ISP) shifts to IPv6 service due
   to lack of global IPv4 address.  Although there are several ways to
   provide commercial IP services to customers, this document explains
   how Network Mobility technology is applicable even for fixed network
   service.  This document shows the possible configuration and
   operation of Network Mobility (NEMO) for commercial fixed network
   service.  We also describes the missing functionalities of NEMO in
   terms of the commercial ISP services.

   Readers are expected to be familiar with all the terms defined in
   'Mobility Related Terminology' [RFC-3753] and 'Network Mobility
   Support Terminology' [RFC-4885].

   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 [RFC-2119].

































Wakikawa & Miyakawa      Expires January 5, 2009                [Page 3]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


2.  System Design and Concept

2.1.  Concept

   NEMO technology might let ISP shift to IP based service from PPP
   based operation, though there is no mobility involvement.  The left
   figure of Figure 1 shows the typical network configurations of Access
   Service Provider (ASP) and ISP for commercial network services.
   There are several access medias between ISP and User's site such as
   ADSL, Fiber, DSL.  In the most deployment case, point-to-point link
   is established between ISP and user's site by PPPoE, PPPoA and so on.
   PC1 and PC2 are depicted as user's machines in Figure 1.


        +--------------+                  +--------------+
        |      ISP     |                  |      ISP     |
        +------+-------+                  +------+-------+
               |                                 |
              PE: Provider Edge                 HA: Home Agent
          ASP  |                            ASP ||
               | point-to-point link            || Bi-directional tunnel
               |                                ||
              CPE: Customer Premises            MR: Mobile Router
               |   Equipment                     |
         -+----+----+-                     -+----+----+-
          |         |                       |         |
         PC1       PC2                     PC1       PC2
      (User's Site Network)               (Mobile Network)



                        Figure 1: Network Overview

   The right figure shows the configuration of the NEMO Basic Support
   Protocol [RFC-3963].  RFC3963 is used to provide a network access to
   user's site from ISP.  Mobile Router acts as CPE and HA takes role of
   PE as shown in the right figure of Figure 1.  ISP operates a home
   agent and a mobile router is located at each user's home/office.  We
   summarize the configuration in below.

   o  ISP is an operator of Home Agent and Home Network.  It provides:

      1.  IPv6 Home Address to a mobile router

      2.  IPv6 Mobile Network Prefix(es) to a mobile router

      3.  IPv4 Home Address(es) to a mobile router




Wakikawa & Miyakawa      Expires January 5, 2009                [Page 4]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


   o  ASP is an operator of Foreign Network and provides:

      1.  Care-of Address(IPv4 or IPv6) to a mobile router

   o  User is living at a Mobile Network.

      1.  All the required information is obtained from both ISP and
          ASP.

      2.  User's site network is provided as a mobile network of NEMO.

   The idea is to replace PPP between PE and CPE by IP-in-IP tunnel
   managed by NEMO.  The Home Agent assigns both IPv4 and IPv6 addresses
   to a mobile router.  The mobile router owned by users acquires a
   care-of address from ASP and registers that care-of address to ISP's
   home agent as a binding.

   Figure 2 shows the possible network overview when ASP and ISP
   commercial services are operated by NEMO.  When a user buy IP
   connectivity service, a MR is installed in each home and obtained IP
   addressed from respective home agent of which the user subscribes.
   ASP provides addresses to each MR and IP forwarding capability to and
   from the MR.




























Wakikawa & Miyakawa      Expires January 5, 2009                [Page 5]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


                                 Internet
                            /|\            /|\
                             |              |
                            ISP1           ISP2
                   2001:DB8:1::/48     2001:DB8:2::/48
                          a.b.c/n        d.e.f/n
                           +-+--+         +-+--+
                           |HA1 |         |HA2 |
                           +-++-+         +-++-+
                           | || |         | || |
                      _.---| || |---------| || |---.
             _.-----''     | || |         | || |    `-------.
        ,--''              | || |         | || |             `---.
     ,-'       ____________| || |         | || | IP-in-IP tunnel  `-.
    /         / _____________|| |         | || |__________            \
   (         / /              | |         | ||__________  |            )
    \       / /           ____| |         | |           | |           /
     `-.   | |            | ____|         | |           | |        ,-'
        `--| |            | |             | |           | |   _.--'
           | |`-------.   | |             | |      _.---| |-''
           | |         `--| |-------------| |----''     | |
           | |            | |             | |           | |
          +-+-+          +-+-+          +-+-+          +-+-+
          |MR1|          |MR2|          |MR3|          |MR4|      ...
          +-+-+          +-+-+          +-+-+          +-+-+
            |              |              |              |
          --+--          --+--          --+--          --+--
       User's Site1   User's Site2   User's Site3    User's Site4 ...


                       Figure 2: NEMO Network Design

2.2.  The Advantages of NEMO technology for ISP

   NEMO has been standardized for mobility purpose.  There are several
   reasons to use NEMO technology for ISP listed below.

   IPv4 and IPv6 Connectivity

      A mobile router obtains an IPv6 home address and more than one
      IPv6 mobile network prefixes for its mobile network.  By using
      DSMIPv6 extension [ID-DSMIP6], IPv4 home address(es) can also be
      assigned to a mobile router.  Therefore, both IPv4 and IPv6
      connectivity can be provided to User's site network.







Wakikawa & Miyakawa      Expires January 5, 2009                [Page 6]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


   Flexibile Placement of Mobile Router

      The NEMO needs a care-of address for its binding registration.
      The original NEMO [RFC-3963] requires IPv6 address as a care-of
      address.  The global address is preferred, but there is not
      technical limitation for using non-global address.  In addition,
      with DSMIPv6 extension, a mobile router can use any of IP
      addresses such as IPv4 private address and IPv4 global address as
      a care-of address.  The appropriate tunnel such as UDP-IP tunnel,
      IPv4-IPv6 tunnel or IPv6-IPv6 tunnel can be established between a
      mobile router and a home agent.  The tunnel is automatically
      established as long as a mobile router obtains a care-of address
      at a visiting network.  Thanks to NEMO and DSMIP, a mobile router
      can be attached to any kinds of network and send a binding update
      to its home agent.

   Flexible Transition from the current Architecture

      The NEMO architecture is similar to what the current system is
      designed with PPP.  The ISP and ASP can inherit the current system
      during this transition period.  It is also independent from access
      media technologies.

   ASP and ISP Independent Authentication

      As shown in Section 2.1, ISP and ASP manage the different type of
      "IP networks".  Thus, both ISP and ASP may be able to authenticate
      each user during the address assignment.  For example, ISP
      authenticate the user when it delegates an IPv6 home address, an
      IPv6 prefix(es) (mobile network prefix) and an IPv4 home
      address(es) to a mobile router, while ASP authenticates the user
      when it provides a care-of address to the mobile router..

   Possible Route Optimization

      The traffic between users' site networks has increased due to
      deployment of P2P applications.  The route optimization inside ASP
      becomes strong requirements of ASP.  Although NEMO does not
      support route optimization at this moment, it should be extensible
      to this optimization in the future.  The MEXT working group has
      discussed the route optimization for NEMO.

   Multihoming Capability

      NEMO is extensible to support User's site-multihoming.  A user can
      subscribe to the same ISP with multiple ASPs.  RFC4908 [RFC-4908]
      describes the detail of NEMO site-multihoming capability.




Wakikawa & Miyakawa      Expires January 5, 2009                [Page 7]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


   Movement Transparency

      Even if a user changes the attachment point or even changes ASP
      due to the user's moving (ex. moving house), the user can continue
      using the same ISP configuration.  This is also great advantage
      for ISP to continue serving the user regardless of the user's
      location.

   Flexibile Multicast Management and Optimization

      There are two different way for nodes in a mobile network to
      subscribe a multicast group.  One way is called home subscription
      where nodes join to the multicast group through ISP.  The nodes
      join the multicast group with an address obtained from the mobile
      router.  The multicast control traffic such as MLD request are
      captured by the mobile router and tunneled to the Home Agent.
      Another way is named remote subscription where nodes join to the
      multicast group at ASP network.  The mobile router acts as a proxy
      MLD and forwards the MLD request from nodes in the mobile network
      to ASP.  As a result, the user's node can join to either ISP or
      ASP multicast service, or both by using these approaches.  The
      tree can be maintained optimal.





























Wakikawa & Miyakawa      Expires January 5, 2009                [Page 8]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


3.  Technical Consideration

3.1.  Expected Basic Technology

   NEMO and DSMIPv6 are mandatory to provide IPv4 and IPv6 connectivity.
   DSMIPv6 has two functionalities: providing IPv4 mobility support and
   IPv4 transport support.  ASP can easily transit from IPv4 to IPv6,
   because a mobile router can place at either IPv4 global/private
   network, IPv6 network, or mixed of them.  It is also benefical for a
   user to provide both IPv4 and IPv6 connectivity.

   o  [RFC-3963]: Network Mobility (NEMO) Basic Support Protocol

   o  [ID-DSMIP6]: Mobile IPv6 support for dual stack Hosts and Routers
      (DSMIPv6)

   ISP requires to operate the large number of subscribers.  NEMO
   Working Group summarizes how to manage the home network in several
   ways.

   o  [RFC-4887]: Network Mobility Home Network Models

   For the mobile network prefix delegation, the following proposal is
   available

   o  [ID-NEMOPD]: DHCPv6 Prefix Delegation for NEMO

3.2.  Security and AAA

   NEMO protocol is designed to protect all the signaling by IPsec as
   same as Mobile IPv6.  However, since the access network is securely
   managed and operated by Access Service Provider (ASP), IPsec is not
   always necessary for binding signaling.  User cannot pull the wired
   cable in their home or office and cannot activate it without ASP
   service contract. (i.e.  Physical level security is available).
   Therefore, Authentication Protocol [RFC-4285] is sufficient for
   securing binding updates in some scenarios although IPsec can be also
   employed.

   o  [RFC-3776]: Using IPsec to Protect Mobile IPv6 Signaling Between
      Mobile Nodes and Home Agents

   o  [RFC-4887]: Mobile IPv6 Operation with IKEv2 and the Revised IPsec
      Architecture

   o  [RFC-4285]: Authentication Protocol for Mobile IPv6

   In NEMO, both IPv4/IPv6 home address and mobile network prefix(es)



Wakikawa & Miyakawa      Expires January 5, 2009                [Page 9]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


   are provided by ISP after AAA transaction.  There are several
   proposals to authenticate Mobile IPv6 resources such as home address
   and mobile network prefix:

   o  [ID-AAAGOAL]: AAA Goals for Mobile IPv6

   o  [ID-MIPRADIUS]: RADIUS Mobile IPv6 Support

   For an IPv4/IPv6 care-of address, ASP can utilize any kinds of
   mechanism of address assignment such as DHCP, PPPo{E/A} and address
   autoconfiguration, etc.  The care-of address assignment is exact same
   as the regular IPv6 address assignment.

3.3.  Route Optimization Support

   ASP has certain needs for Route optimization between User's sites.
   Several P2P applications exchange traffic between User's site.
   Without route optimization, all traffic will be routed to the
   Internet and came back to the same ASP.  This is redundant operation
   and should be avoided.  Two scenarios can be considered whether route
   optimization must be achieved between User's sites operated by either
   same or different ISPs.  Figure 3 shows the example.  MR2 and MR3 are
   operated by different ISPs, while MR3 and MR4 are operated by the
   same ISP.

   We also need to consider that the ASP provides non global care-of
   address as a care-of address.  Even for non global care-of address,
   route optimization can be achieved within the same ASP.























Wakikawa & Miyakawa      Expires January 5, 2009               [Page 10]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


                                   Internet
                              /|\            /|\
                               |              |
                              ISP1           ISP2
                      2001:DB8:1::/48     2001:DB8:2::/48
                            a.b.c/n        d.e.f/n
                             +-+--+         +-+--+
                             |HA1 |         |HA2 |
                             +-+--+         +-+--+
                               |              |
                       _.------+--------------+----.
               _.-----''                             `-------.
          ,--''                                               `---.
       ,-'                                                         `-.
      /                                                               \
     (                                                                 )
      \                       RO(MR2<->MR3)     RO(MR3<->MR4)         /
       `-.                   _______________ ________________       ,-'
          `---.             | _____________ || _____________ |  _.--'
              |`-------.    | |           | || |     _.----| |''
              |          `--| |-----------| || |----''     | |
              |             | |           | || |           | |
            +-+-+          +-+-+          +-+--+          +-+-+
            |MR1|          |MR2|          |MR3 |          |MR4|      ...
            +-+-+          +-+-+          +-+--+          +-+-+
              |              |              |              |
            --+--          --+--          --+--          --+--
         User's Site1   User's Site2   User's Site3    User's Site4 ...


                     Figure 3: NEMO Route Optimization

   NEMO does not support route optimization at this point, but the MEXT
   working group has discussed the useful scenarios of route
   optimization.  The available documents are:

   o  [RFC-4888]: Network Mobility Route Optimization Problem Statement

   o  [RFC-4889]: Network Mobility Route Optimization Solution Space
      Analysis

   o  [ID-AEROREQ]: NEMO Route Optimization Requirements for Operational
      Use in Aeronautics and Space Exploration Mobile Networks

   o  [ID-AUTOREQ]: Automotive Industry Requirements for NEMO Route
      Optimization





Wakikawa & Miyakawa      Expires January 5, 2009               [Page 11]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


3.4.  Site Multihoming Support

   Site-multihoming is easily provided with NEMO.  There is an extension
   to register multiple care-of addresses of a mobile router to home
   agent.  The extension is being standardized at MEXT Working Group
   [ID-MCOA].  A user subscribes multiple ASPs and single ISP.  For
   better optimization, the ISP should have relationship with the ASPs
   to which user subscribe, but this is not mandatory.

   o  [RFC-4908]: Multihoming for Small-Scale Fixed Networks Using
      Mobile IP and Network Mobility (NEMO)

   o  [ID-MCOA]: Multiple Care-of Addresses Registration




      +-------------------------+
      |     The Internet        |
      +-----------+-------------+
                  |  ISP
                +-+--+
             +--| HA |---+
             |  +----+   |
             |           |
             |           |
          ASP-A         ASP-B
             |           |
             |   +---+   |
             +---|MR |---+
            CoA1 +---+ CoA2
                   |
            -------+---------
         Multihomed Network (User's Site)


                        Figure 4: Site Multihoming














Wakikawa & Miyakawa      Expires January 5, 2009               [Page 12]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


4.  IANA considerations

   This document does not require any IANA action.
















































Wakikawa & Miyakawa      Expires January 5, 2009               [Page 13]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


5.  Security Considerations

   Security vulnerability is not introduced in this specification.


Appendix A.  References


A.1.  Normative References

   [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
   in IPv6", RFC 3775, June 2004.

   [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
   Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
   January 2005.

   [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack
   Hosts and Routers (DSMIPv6)",
   draft-ietf-mext-nemo-v4traversal-04.txt, June 2008.

A.2.  Informative References

   [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and
   K. Kuladinithi, "Motivations and Scenarios for Using Multiple
   Interfaces and Global Addresses",
   draft-ietf-monami6-multihoming-motivation-scenario-02 (work in
   progress), July 2007

   [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and
   K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
   draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver
   2007.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
   RFC 3753, June 2004.

   [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
   Terminology", RFC 4885, July 2007.

   [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
   IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007.

   [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of
   Multihoming in Network Mobility Support", RFC 4980, October 2007.



Wakikawa & Miyakawa      Expires January 5, 2009               [Page 14]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


   [RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
   Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC-4908] K. Nagami, et. al, "Multihoming for Small-Scale Fixed
   Networks Using Mobile IP and Network Mobility (NEMO)", RFC 4908, June
   2007.

   [RFC-4887] P. Thubert, et. al, "Network Mobility Home Network
   Models", RFC 4887, July 2007.

   [RFC-4285] A. Patel, et. al,"Authentication Protocol for Mobile
   IPv6", RFC 4285, January 2006.

   [ID-AAAGOAL] G. Giaretta, et. al, "AAA Goals for Mobile IPv6",
   draft-ietf-mext-aaa-ha-goals-01.txt, May 2008.

   [ID-MIPRADIUS] A. Lior, et. al, "RADIUS Mobile IPv6 Support",
   draft-ietf-mip6-radius-04.txt, February 2008.

   [ID-NEMOPD] R. Droms, et. al, "DHCPv6 Prefix Delegation for NEMO",
   draft-droms-mext-nemo-pd-00.txt, May 2008.

   [RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization
   Problem Statement", RFC 4888, July 2007.

   [RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization
   Solution Space Analysis", RFC 4889, July 2007.

   [ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements
   for Operational Use in Aeronautics and Space Exploration Mobile
   Networks", draft-ietf-mext-aero-reqs-02.txt, May 2008.

   [ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements
   for NEMO Route Optimization",
   draft-ietf-mext-nemo-ro-automotive-req-00.txt, February 2008.

   [ID-MCOA] R. Wakikawa, et. al, "Multiple Care-of Addresses
   Registration", draft-ietf-monami6-multiplecoa-08.txt, May 2008.













Wakikawa & Miyakawa      Expires January 5, 2009               [Page 15]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


Authors' Addresses

   Ryuji Wakikawa
   Toyota ITC / Keio University
   6-6-20 Akasaka, Minato-ku
   Tokyo  107-0052
   Japan

   Phone: +81-3-5561-8276
   Fax:   +81-3-5561-8292
   Email: ryuji@jp.toyota-itc.com


   Shin Miyakawa
   Innovative IP Architecture Center, NTT Communications Corporation
   Tokyo Opera City Tower 21F, 3-20-2
   Nishi-Shinjuku, Shinjuku-ku,
   Tokyo
   Japan

   Phone: +81-3-6800-3262
   Email: miyakawa@nttv6.jp





























Wakikawa & Miyakawa      Expires January 5, 2009               [Page 16]

Internet-Draft          NEMO Applicabiliy to ISP               July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Wakikawa & Miyakawa      Expires January 5, 2009               [Page 17]