Internet DRAFT - draft-xia-16ng-per-ms-prefix-nd

draft-xia-16ng-per-ms-prefix-nd






Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Intended status: Standards Track                              Huawei USA
Expires: February 26, 2007                                      B. Patil
                                                                   Nokia
                                                         August 25, 2006


Neighbor Discovery and Address Autoconfiguration in Per-MS Subnet Prefix
                                 Model
                   draft-xia-16ng-per-ms-prefix-nd-00

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 February 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).











Xia, et al.             Expires February 26, 2007               [Page 1]

Internet-Draft      ND and Address Autoconfiguration         August 2006


Abstract

   This draft defines neighbor discovery and stateless address
   autoconfiguration based on IEEE 802.16d/e per-MS subnet prefix model.
   In this model, an MS can have multiple IPv6 addresses, but an IPv6
   prefix can only be used by one MS, that is, different MSs cannot
   share the same prefix.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Virtual Link . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Virtual Link States Transitions  . . . . . . . . . . . . .  6
       3.1.1.  Active . . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.2.  Shutdown . . . . . . . . . . . . . . . . . . . . . . .  6
       3.1.3.  Teardown . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Information Model  . . . . . . . . . . . . . . . . . . . .  7
   4.  Prefix Assignment  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Fast Router Discovery (FRD)  . . . . . . . . . . . . . . .  8
     4.2.  Solicited Router Advertisement . . . . . . . . . . . . . .  8
     4.3.  Periodic Router Advertisement  . . . . . . . . . . . . . .  8
   5.  Link Local Address Autoconfiguration . . . . . . . . . . . . .  9
     5.1.  Interface Identifier . . . . . . . . . . . . . . . . . . .  9
     5.2.  Duplicate Address Detection  . . . . . . . . . . . . . . .  9
   6.  Global Address Autoconfiguration . . . . . . . . . . . . . . . 10
   7.  Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Reuse of existing standards  . . . . . . . . . . . . . . . 11
     7.2.  On-link Multicast Support  . . . . . . . . . . . . . . . . 11
     7.3.  Consistency in IP Link Definition  . . . . . . . . . . . . 11
     7.4.  Packet Forwarding  . . . . . . . . . . . . . . . . . . . . 11
     7.5.  Effect on Dormant Mode . . . . . . . . . . . . . . . . . . 11
     7.6.  Changes on Host Implementation . . . . . . . . . . . . . . 11
     7.7.  Changes on Router Implementation . . . . . . . . . . . . . 12
     7.8.  Renumbering  . . . . . . . . . . . . . . . . . . . . . . . 12
     7.9.  SeND Support . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18







Xia, et al.             Expires February 26, 2007               [Page 2]

Internet-Draft      ND and Address Autoconfiguration         August 2006


1.  Introduction

   While the IEEE 802.16d/e defines the encapsulation of an IPv4/IPv6
   datagram in an IEEE 802.16d/e MAC payload, a complete description of
   IPv4/IPv6 operation and deployment is not present.  This draft will
   describe Neighbor Discovery behavior between MS and AR based on
   Per-MS subnet prefix model.

   Figure 1 illustrates the key elements of a typical IEEE 802.16d/e
   access network.

      Customer |      Access Provider      | Service Provider
      Premise  |                           | (Backend Network)

    +-----+            +-----+     +------+   +--------+
    | MSs |--(802.16)--| BS  |-----+Access+---+ Edge   |    ISP
    +-----+            +-----+     |Router|   | Router +==>Network
                                   +--+---+   +--------+
    +-----+            +-----+        |            |  +------+
    | Mss |--(802.16)--| BS  |--------+            +--|AAA   |
    +-----+            +-----+                        |Server|
                                                      +------+

     Figure 1: key elements of a typical IEEE 802.16d/e access network

   MSs attach BS through 802.16d/e air interface.  A BS manages
   connectivity of MSs and extend connections to an Access Router.  An
   access router is the first IP hop router for MSs.

   In the shared prefix model, an IPv6 prefix is shared by multiple MSs.
   [IPV6CS] defines ND behavior based on this model.  There are some
   cons in this model, such as,

   1.  complicated DAD because of lack of link-local multicast
       mechanism,

   2.  complicated maintenance of an authoritative address cache,
       especially in the scenario that address changes frequently
       especially when CGA based addresses are used.

   Shared subnet prefix model can be viewed as a kind of multilink
   subnets model.  For a more in-depth analysis of multilink subnets,
   see [MULTILINK].

   Per-MS subnet prefix model was first proposed for 3GPP networks in
   [RECOMMENDATION].  We propose a similar per-MS subnet prefix model
   for IEEE 802.16d/e network architecture in this document.  That is, a
   prefix is only assigned to one MS, different MSs can't share a



Xia, et al.             Expires February 26, 2007               [Page 3]

Internet-Draft      ND and Address Autoconfiguration         August 2006


   prefix, and an MS can have multiple prefixes.  The later sections
   will detail ND and address stateless autoconfiguration under this
   model.
















































Xia, et al.             Expires February 26, 2007               [Page 4]

Internet-Draft      ND and Address Autoconfiguration         August 2006


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 BCP 14 [STANDARDS].

   subnet: generally used to refer to a topological area that uses the
   same address prefix, where that prefix is not further subdivided
   except into individual addresses.  In this draft, an IPv6 prefix used
   stands for a subnet.

   link: A communication facility or physical medium that can sustain
   data communications between multiple network nodes, such as an
   Ethernet.  A subnet (prefix)is associated with one link.  Multiple
   subnets(prefixes) may be assigned to the same link.  Different links
   can not share the same prefix.

   transport connection: An 802.16d/e based MAC connection between an MS
   and a BS with specific QoS attributes.  There can be multiple
   connections between an MS and a BS at any given time serving
   different QoS requirements of the end user applications.  Each
   connection is identified by an unique identifier called Connection
   Identifier (CID).  In the separated model where an AR and a BS are
   separated physically, tunnels are established between the AR and the
   BS.  Tunnels can be viewed as an physical extension of a transport
   connection.

   virtual link: this is a logical concept above transport connections
   between an MS and an AR.  From IP layer perspective, there are no
   differences between virtual and real links.

   virtual interface: either end of a virtual link connects the link
   through a virtual interface.  Each interface has a 64bit identifier
   which can be used for identifying the virtual link.  On a given link,
   an MS and an AR have independent virtual interface identifiers which
   can be used for configuring a separate link local address, or a
   global IP address.  Each node can have more than one virtual
   interface for multihoming.













Xia, et al.             Expires February 26, 2007               [Page 5]

Internet-Draft      ND and Address Autoconfiguration         August 2006


3.  Virtual Link

   An MS performs initial network entry and authentication procedures as
   described in 802.16d/e.  Then an initial transport connection is
   established between an MS and an AR.  The MS or AR may create, modify
   or delete transport connections dynamically.  IPv6 operations run on
   transport connections.

   When an MS is in idle mode, all related transport connections are
   destroyed.  The MS keeps the IPv6 address unchanged.

   When an MS switches off or hands off, all the connections are
   destroyed.  The prefixes assigned should be released.

   A virtual link is a logical concept which consists of one or more
   transport connections.  An MS can have one or more virtual links to
   an AR.  Each virtual link has one or more prefixes, while each prefix
   can only be used in one virtual link.

3.1.  Virtual Link States Transitions

3.1.1.  Active

   When an initial transport connection is created, a virtual link is
   also created at the same time and the state is active.  In this
   state, transport connections can be added, modified, and deleted to
   this link.  From IP layer perspective, the virtual link is not any
   different from such links as Ethernet, PPP.  ND can run on a virtual
   link in active state without any modifications.

3.1.2.  Shutdown

   When an MS becomes dormant, all connections are destroyed, and
   related virtual link's state becomes shutdown.  In this state, the MS
   holds it's IPv6 address, and the link attributes such as prefixes
   keep unchanged, but there are no ND signaling exchanges between the
   MS and the AR.  When the MS initiates a session or receives an
   incoming session, one or more transport connections are added to the
   virtual link, and the state transits to an active one.

3.1.3.  Teardown

   When an MS switches off or is handed over, a virtual link is torn
   down, and all the transport connections are destroyed.  Prefixes
   assigned to the virtual link SHOULD be released.






Xia, et al.             Expires February 26, 2007               [Page 6]

Internet-Draft      ND and Address Autoconfiguration         August 2006


3.2.  Information Model

   Neighbor discovery protocol runs on a virtual link.  When an MS
   receives NS/NA/RA or an AR receives NS/NA/RS from a CID, these nodes
   will map the CID to a related virtual link for further process.  When
   an MS sends NS/NA/RS or an AR sends NS/NA/RA to a virtual link, these
   nodes will map the virtual link to a related CID for transport.

   Each MS and AR have a virtual link information table which include
   following elements:

   1.  virtual interface identifier which can be used to identify the
       virtual link.  For the same virtual link, an AR and an MS create
       their virtual interfaces independently.  In the same node,
       different interfaces MUST have different identifiers.

   2.  prefixes which are assigned to the link for address
       autoconfiguration.

   3.  CIDs which compose the virtual link.

   4.  optional items such as MTU and so on.

   When an MS hands over to another BS under the same AR, the MS and the
   AR deletes the existing CIDs and adds one or more new CIDs.  Other
   attributes of this entry including prefixes are kept unchanged.

   When an MS becomes dormant, the MS and AR deletes all existing CIDs.
   When the MS becomes active again, new CIDs are created and added to
   the entry.





















Xia, et al.             Expires February 26, 2007               [Page 7]

Internet-Draft      ND and Address Autoconfiguration         August 2006


4.  Prefix Assignment

   When an MS attaches to an AR, prefixes SHOULD be assigned to the MS.
   When the MS detaches from the AR, prefixes SHOULD be reclaimed.  The
   AR can manage prefixes through DHCPv6.  That is, when the AR needs to
   assign prefixes to an MS, it requests these prefixes from a DHCP
   server, and when the MS detaches the AR, the AR gives back the
   prefixes to the DHCP server.  There are also some alternatives to
   manage prefixes.  In this memo, how an AR assigns prefixes to an MS
   is our topic.

4.1.  Fast Router Discovery (FRD)

   As soon as a virtual link becomes active, an AR sends a suitable
   unsolicited RA.  In this message, one or more prefixes are included.

4.2.  Solicited Router Advertisement

   When a virtual link is active, an MS sends an RS with all-routers
   multicast address as destination address and unspecified address as
   source address on the link.  The AR responds with a suitable RA with
   all-nodes multicast address as the destination IP address and the AR
   link local address as the source address.

4.3.  Periodic Router Advertisement

   When a virtual link is active, periodic router advertisement SHOULD
   be performed as per [DISCOVERY].  When an MS is in idle mode, the
   corresponding virtual link is in shutdown state, and an AR never
   advertises an RA message on a shutdown link.  Thus an MS never wakes
   up just because of receiving a RA.  The MaxRtrAdvInterval should be
   configurable to quite a high value to relieve RA traffic through air
   interface.


















Xia, et al.             Expires February 26, 2007               [Page 8]

Internet-Draft      ND and Address Autoconfiguration         August 2006


5.  Link Local Address Autoconfiguration

5.1.  Interface Identifier

   An MS can generate it's interface identifier from its MAC address as
   per [ARCHI].  The MS may also generate random interface identifiers
   as per [PESAA].  An AR generates an identifier for a virtual
   interface as it does for a physical one.

5.2.  Duplicate Address Detection

   When a virtual link is created, an MS and an AR create their
   respective link local addresses and do DAD within the link
   independently.





































Xia, et al.             Expires February 26, 2007               [Page 9]

Internet-Draft      ND and Address Autoconfiguration         August 2006


6.  Global Address Autoconfiguration

   An AR advertises the prefixes by putting PIO (Prefix Information
   Option) in the Router Advertisements and an MS learns the prefix
   information by consulting these PIOs.  The MS and the AR concatenate
   prefix and interface ID to create their own global addresses
   independently.  DAD is done within the virtual link scope.












































Xia, et al.             Expires February 26, 2007              [Page 10]

Internet-Draft      ND and Address Autoconfiguration         August 2006


7.  Considerations

7.1.  Reuse of existing standards

   In this model, almost all the work is focused on how to maintain a
   virtual link.  From IP layer perspective, there is no difference
   between a real link and a virtual one.  So, ND protocol can run on a
   virtual link without any modification and limitation.

7.2.  On-link Multicast Support

   Only an MS and an AR connect to a virtual link.  On-link multicast is
   supported, but the scope is limited.  On-link multicast is the same
   as unicast.

7.3.  Consistency in IP Link Definition

   In [MULTILINK], there is IP Link definition and explanation.  The
   main idea is that a subnet is considered to be a subset of a link.
   That is, a link can have one or more subnets, but one subnet can only
   span one link.

   In per-MS subnet prefix model, a prefix can be viewed as a subnet.  A
   virtual link can be assigned to one or more prefixes, while one
   prefix can only be used by one link.  This model is consistent with
   original IP model.

7.4.  Packet Forwarding

   From a data plane perspective, an AR behavior is almost the same as a
   router.  The difference is that a router has limited static physical
   interfaces while an AR has many dynamic virtual interfaces.  The AR
   broadcasts prefix route information to the Internet.  An aggregated
   route can be used to avoid route flips.

7.5.  Effect on Dormant Mode

   Link-local multicast is limited in a virtual link.  An MS is waken up
   only when there is some traffic.  Thus, battery can be used
   efficiently.

7.6.  Changes on Host Implementation

   Virtual links MUST be maintained to provide a consistent interface to
   the IP layer.  Any function modules above the link layer can be used
   without any modification.  As there is very low address duplication
   possibility, Optimistic DAD as per [OPTDAD] is preferable.




Xia, et al.             Expires February 26, 2007              [Page 11]

Internet-Draft      ND and Address Autoconfiguration         August 2006


7.7.  Changes on Router Implementation

   Following functions should be added in an AR

   1.  virtual link management: to create and destroy links, and to
       maintain links' states.

   2.  prefix management: to allocate and reclaim prefixes for MSs

   3.  route management: to broadcast MSs route information dynamically.

   Prefix management can be considered with route management at the same
   time.  For example, each AR can be assigned a /48 prefix, while an
   MS' /64 prefix is derived from the /48 prefix extension.

7.8.  Renumbering

   Each prefix has it's lifetime, and multiple prefixes can be assigned
   to a virtual link at the same time.  Renumbering function can be
   obtained.  For example, if a carrier wants to change it's /48 prefix,
   all corresponding /64 prefixes MUST be advertised to MSs.  Compared
   to the shared subnet prefix model, per-MS subnet prefix has more
   signaling traffic while renumbering.

7.9.  SeND Support

   An MS can generate an virtual interface identifier of an IPv6 address
   by computing a cryptographic hash of the public key.

   SeND is supported.





















Xia, et al.             Expires February 26, 2007              [Page 12]

Internet-Draft      ND and Address Autoconfiguration         August 2006


8.  Applicability

   This model is applicable for both IPv6 CS and Ethernet CS.  It can be
   used not only Integrated AR-BS model (Profile B in WiMAX
   architecture) but also separated AR-BS one (Profiles A and C).














































Xia, et al.             Expires February 26, 2007              [Page 13]

Internet-Draft      ND and Address Autoconfiguration         August 2006


9.  Security Considerations

   There are existing security concerns with Neighbor Discovery and
   Stateless Address Auto configuration.  Secure Neighbor Discovery
   (SEND) [SEND] provides protection against the threats to Neighbor
   Discovery described in [NDTM].  This memo does not introduce any
   additional threats to Neighbor Discovery, and SEND can be used.












































Xia, et al.             Expires February 26, 2007              [Page 14]

Internet-Draft      ND and Address Autoconfiguration         August 2006


10.  References

10.1.  Normative References

   [ADDRCONF]
              Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998,
              <ftp://ftp.isi.edu/in-notes/rfc2462>.

   [ARCHI]    Hinden, R. and S.  Deering, "IP Version 6 Addressing
              Architecture", RFC 4921, February  2006,
              <ftp://ftp.isi.edu/in-notes/rfc4291>.

   [DISCOVERY]
              Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998, <ftp://ftp.isi.edu/in-notes/rfc2461>.

   [MLD]      Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery for IPv6", RFC 2710, October 1999,
              <ftp://ftp.isi.edu/in-notes/rfc2710>.

   [NDTM]     Nikander, P., Kempf, J., and E.  Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004, <ftp://ftp.isi.edu/in-notes/rfc3756 >.

   [OPTDAD]   Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006,
              <ftp://ftp.isi.edu/in-notes/rfc4429>.

   [PESAA]    Narten, T. and R. Draves, "Privacy Extensions for
              Stateless Address Autoconfiguration in IPv6", RFC 3041,
              January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.

   [RECOMMENDATION]
              Wasserman, Ed., M., "Recommendations for IPv6 in Third
              Generation Partnership Project (3GPP) Standards",
              RFC 3314, September 2002,
              <ftp://ftp.isi.edu/in-notes/rfc3314>.

   [SEND]     Arkko, J., Kempf, J., Zill, B., and P. Nikander, "Secure
              Neighbor Discovery (SEND)", RFC 3971, March 2005,
              <ftp://ftp.isi.edu/in-notes/rfc3971>.

   [STANDARDS]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement  Levels", RFC 2119, March 1997,
              <ftp://ftp.isi.edu/in-notes/rfc2119>.



Xia, et al.             Expires February 26, 2007              [Page 15]

Internet-Draft      ND and Address Autoconfiguration         August 2006


10.2.  Informative References

   [IPV6CS]   Madanapalli,  S., Patil, B., Nordmark, E., Choi, J., and
              S. Park, "Transmission of IPv6 over 802.16's IPv6
              Convergence Sublayer", June 2006, <http://www.ietf.org/
              internet-drafts/
              draft-madanapalli-ipv6-over-802.16-ipv6cs-00.txt>.

   [MULTIENCAP]
              Aboba,Ed.,  B., Davies, Elwyn., and Dave. Thaler,
              "Multiple Encapsulation Methods Considered Harmful",
              July 2006, <http://www.ietf.org/internet-drafts/
              draft-iab-link-encaps-02.txt>.

   [MULTILINK]
              Thaler, Dave., "Issues With Protocols Proposing Multilink
              Subnets", February 2006, <http://www.ietf.org/
              internet-drafts/
              draft-thaler-intarea-multilink-subnet-issues-00.txt>.
































Xia, et al.             Expires February 26, 2007              [Page 16]

Internet-Draft      ND and Address Autoconfiguration         August 2006


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Email: sarikaya@ieee.org


   Basavaraj Patil
   Nokia
   6000 Connection Drive
   Irving, TX  75039

   Phone:
   Email: basavaraj.patil@nokia.com

























Xia, et al.             Expires February 26, 2007              [Page 17]

Internet-Draft      ND and Address Autoconfiguration         August 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 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).





Xia, et al.             Expires February 26, 2007              [Page 18]