Network Working Group                                           J. Zhang
Internet-Draft                                             China Telecom
Intended status: Standards Track                                 T. Tsou
Expires: January 17, 2013                      Huawei Technologies (USA)
                                                                  W. Liu
                                                     Huawei Technologies
                                                                  J. Sun
                                                           China Telecom
                                                           July 16, 2012


                  IPv6 over ATM Interworking Function
                    draft-zhang-v6ops-ipv6oa-iwf-01

Abstract

   This document describes an interworking function between IPv6 over
   ATM (Asynchronous Transfer Mode) and IPv6 over Ethernet.  The
   interworking function enables the communication between ATM and
   Ethernet by maintaining the multiple states of both of them.

Requirements Language

   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].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 17, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Zhang, et al.           Expires January 17, 2013                [Page 1]


Internet-Draft                 IPv6oA-IWF                      July 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Context and Scope . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Context and Scope . . . . . . . . . . . . . . . . . . . . . 4
   4.  Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  A general topology for IPv4 and IPv6 networks . . . . . . . 4
     4.2.  Address resolution for downstream . . . . . . . . . . . . . 5
     4.3.  Address resolution for upstream . . . . . . . . . . . . . . 6
     4.4.  Link layer address change in packets  . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7






















Zhang, et al.           Expires January 17, 2013                [Page 2]


Internet-Draft                 IPv6oA-IWF                      July 2012


1.  Introduction

   The IPv4 exhaustion problem draws the attention of the world.  There
   are a number of issues to deal with when network migrates to IPv6.
   The use of IPoA encapsulation on the U-interface in legacy ATM access
   networks is predominantly applicable to business users.  IP addresses
   used in the network behind the RG are exchanged using routing
   protocols that run transparently over the ATM PVCs.  Currently, IPoA
   encapsulation is migrated to an Ethernet aggregation network in
   [TR101].  This is achieved by means of an IPoA Interworking Function
   in IPv4 network.  This model should continue to be supported in IPv6
   scenario.

   In this draft we define an Interworking Function for IPv6 to support
   IPv6 over ATM, IPv6 over Ethernet, and IPv6 over SDH.  In IPv4
   network, upon receiving a ARP request transmitted from a BNG, the
   IPoA IWF SHOULD be able to reply with the appropriate MAC address
   used as the source address for upstream packets.  In IPv6 scenario,
   however, address resolution applies Neighbor Discovery Protocol
   [RFC4861], which is in a completely different way.  As the result,
   IPv6oA IWF should support both the IPv6 address resolution and the
   functions of IPv4oA IWF in the following way.

   For upstream packets, the IPoA IWF MUST use a MAC source address that
   is under the control of the Access Node (e.g. the MAC address of the
   Access Node uplink).For upstream unicast packets, the IPoA IWF MUST
   use a MAC unicast destination address of the BNG.  For upstream
   multicast and broadcast packets, the IPoA IWF MUST derive the MAC
   destination address using the standard multicast/broadcast IP address
   to MAC address conversion algorithm.

   For downstream, BNG need to know which downstream interface that it
   should forward to when receiving a packet from internet.  IPv6
   address resolution is necessary in this scenario.  When there are
   multiple BNGs in the metro networks, the IPv6oA IWF need to know
   exactly which BNG it should send to.  In this case IPv6oA IWF need do
   IP address resolution.  If Layer 2 information (such as MAC) is
   included in a Neighbor Discovery packet, IPv6oA IWF need make sure
   the carried information is identical to the layer 2 information in
   packet.  In a word, IPoA IWF should do some additional work when
   networks migrate from IPv4 to IPv6.


2.  Terminology

   This document makes use of the following terms:





Zhang, et al.           Expires January 17, 2013                [Page 3]


Internet-Draft                 IPv6oA-IWF                      July 2012


      IPv6oA IWF: IPv6 over ATM interworking function
      BNG: Broadband Network Gateway is the IP edge where user services
      are performed.
      ATM: Asynchronous Transfer Mode
      RG: Residential Gateway
      PVC: permanent virtual circuit


3.  Context and Scope

3.1.  Context and Scope

   There are many kinds of access protocols between CPE and BNG device.
   When IPv4 network migrates to IPv6 network, the access protocol must
   be taken into account.  This draft outlines how an IPv6 over ATM
   access network, or an IPv6 over SDH can be migrated to an Ethernet
   based IPv6 network.

   This document focuses only on interworking function between IPv6 over
   ATM networks, IPv6 over SDH, and Ethernet based IPv6 networks.  In
   the following, we use IPv6 over ATM to illustrate our main idea.  The
   scenarios include CPE devices that support Inverse Neighbor Discovery
   [RFC3122]and BNG devices that support Neighbor Discovery based on
   Ethernet.  The IPv6oA interworking function makes sure the two kinds
   of devices can communicate smoothly.  The IPv6oA IWF may exist in
   CPEs, BNGs or Access nodes(AN).


4.  Solution Overview

   This section describes solutions for problems mentioned above.

4.1.  A general topology for IPv4 and IPv6 networks
                                           ----------
                                         ///          \\\
    +------+ IPv6 over +-------------+ //                \\ +----------+
    |      | ATM       |             ||                    ||          |
    | CPE  +-----------+  IPv6oA IWF |    Ethernet base     |   BNG    |
    |      |           |             |    IPv6 network      |          |
    +------+           +-------------+|                    |+----------+
                                       \\                //
                                         \\\          ///
                                            ----------


   Figure 1: Topology for IPv6 over ATM IWF

   IPv6oA IWF exists in a node that lies between two kinds of networks,



Zhang, et al.           Expires January 17, 2013                [Page 4]


Internet-Draft                 IPv6oA-IWF                      July 2012


   IPv6 over ATM and Ethernet base IPv6 network, as shown in Figure 1.
   [RFC3122]describes extensions to the IPv6 Neighbor Discovery that
   allow a node to determine and advertise an IPv6 address corresponding
   to a given link-layer address.  These extensions are called Inverse
   Neighbor Discovery (IND).  IPv6 Neighbor Discovery protocol based
   Ethernet is used to discover each other's presence, to determine each
   other's link-layer addresses, to find routers, and to maintain
   reachability information about the paths to active neighbors.  The
   IPv6oA interworking function is proposed to make sure the two kinds
   of devices, CPE devices that support Inverse Neighbor Discovery and
   BNG devices that support Neighbor Discovery based on Ethernet, can
   communicate smoothly.  IPv6oA IWF changes packets from IPoA to IPoE
   in upstream direction and ones from IPoE to IPoA in downstream
   direction, respectively.  The encapsulation specification can be find
   in [TR101].

4.2.  Address resolution for downstream

   When a BNG receives a packet from internet sent to a CPE, if the BNG
   does not know the corresponding link-layer address, it checks the
   neighbor cache entries to get the link layer address, i.e., the MAC
   address in Ethernet.  If the link layer address of corresponding
   destination IP address can not be found there, the BNG initiates an
   address resolution as described in charter 7.2 of [RFC4861].  The BNG
   parses the destination IP address in the packet aiming to the CPE and
   include the parsed IP address in Target Address field of Neighbor
   Solicitation Message.  Then BNG will send Neighbor Solicitation to
   its downstream interface.

   When IPv6oA IWF receives the Neighbor Solicitation Message from a
   BNG, it have to make sure the IP address that need to be resolved is
   on link IP address.  IPv6oA IWF will initiate an Inverse Neighbor
   Discovery Solicitation to CPE.  When IPv6oA IWF receives the Inverse
   Neighbor Discovery Advertisements from a CPE for the resolution IP
   address, it checks the Source/Destination Address List for the IP
   address to be resolved.  If the IP address is in the list, then
   IPv6oA IWF can response the Neighbor Solicitation Message from BNG
   with Neighbor Advertisement Message.  IPv6oA IWF sets the MAC of
   node's upstream interface to Source/Destination Link-layer Address
   option field in Neighbor Advertisement Message.  Then IPv6oA IWF can
   receive packets sent to CPE and forward them according to IPoA
   encapsulation specification.

   When IPv6oA IWF sends Inverse Neighbor Discovery Message, it can
   change the Neighbor Solicitation Message from BNG to Inverse Neighbor
   Discovery Solicitation message or change the Inverse Neighbor
   Discovery Advertisements message from CPE to Neighbor Advertisements
   message since IND protocol is just the extensions to the IPv6



Zhang, et al.           Expires January 17, 2013                [Page 5]


Internet-Draft                 IPv6oA-IWF                      July 2012


   Neighbor Discovery.  IPv6oA IWF can work in layer 2 nodes.  For
   upstream packets, the IPoA IWF MUST use a MAC source address that is
   under the control of the Access Node (e.g. the MAC address of the
   Access Node uplink).For upstream unicast packets, the IPoA IWF MUST
   use a MAC unicast destination address of the BNG.  For upstream
   multicast and broadcast packets, the IPoA IWF MUST derive the MAC
   destination address using the standard multicast/broadcast IP address
   to MAC address conversion algorithm.

4.3.  Address resolution for upstream

   When there are multiple BNGs in a metro network, in other word,
   multiple IP edges in same networks, IPv6oA IWF needs to know which
   BNG it will send according to destination IP in the packets received
   from the CPE.  IPv6oA IWF could configure the different BNG IPs and
   MACs as the next hop by filtering the destination IP address of
   packets to be sent.  If we do not configure this information, IPv6oA
   IWF needs to finish address resolution for upstream packets.  For
   simplicity, it is suggested to manually configure the BNG IP and MAC
   on IPv6oA IWF node.

   When IPv6oA IWF receives Inverse Neighbor Discovery Solicitation, it
   responses Inverse Neighbor Discovery Advertisement with Source/
   Destination Address List in the message.  The Source/Destination
   Address List includes the IPv6 address of BNG's downstream interface.
   Source/Destination Address List can be configured or accessed from
   Neighbor Cache entries.

   When IPv6oA IWF receives IPv6 packets sent to a BNG, it makes address
   resolution.  IPv6oA IWF needs to establish Neighbor Solicitation
   Message and support address resolution mentioned in charter 7.2 of
   [RFC4861].  After it receives Neighbor Advertisement message,
   Neighbor Cache entries will be established according to the reply
   from BNG.  IPv6 IWF then changes IPoA packets to IPoE packets
   according to [TR101].  The destination MAC address and the source MAC
   address are set as the resolved link address and the upstream link
   address of IPv6oA IWF, respectively.

4.4.  Link layer address change in packets

   Inverse Neighbor Discovery Solicitation, Neighbor Solicitation,
   Router Solicitation, and Router Advertisement packets may include a
   Source/Destination Link-layer Address option in the packet.  Inverse
   Neighbor Discovery Advertisement, Neighbor Advertisement and Redirect
   packets may include a Source/Destination Link-layer Address option in
   the packet.  After IPv6oA IWF gets these packets from CPE or from
   BNG, it checks whether there is a Source/Destination Link-layer
   Address option in the packets.  If yes, it changes the Source/



Zhang, et al.           Expires January 17, 2013                [Page 6]


Internet-Draft                 IPv6oA-IWF                      July 2012


   Destination Link-layer Address option value to Ethernet Link-layer
   Address (such as upstream interface MAC address of Access Node that
   IPv6oA IWF lies in ) for upstream packets or ATM Link-layer Address
   for downstream packets.


5.  Security Considerations


6.  Acknowledgments


7.  IANA Considerations




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.

8.2.  Informative References

   [RFC3122]  Conta, A., "Extensions to IPv6 Neighbor Discovery for
              Inverse Discovery Specification", RFC 3122, June 2001.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [TR101]    Boardband-forum, "Migration to Ethernet-Based Broadband
              Aggregation", Jul 2011, <http://www.broadband-forum.org/
              technical/download/TR-101_Issue-2.pdf>.


Authors' Addresses

   Jiexin Zhang
   China Telecom
   NO 1835, Dongnan RD, Pudong DIST
   Shanghai,
   P.R. China

   Email: estrellazhang2012@gmail.com




Zhang, et al.           Expires January 17, 2013                [Page 7]


Internet-Draft                 IPv6oA-IWF                      July 2012


   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com


   Will Liu
   Huawei Technologies
   Bantian, Longgang DIST
   Shenzhen  518129
   P.R. China

   Phone: +86 755 28972315
   Email: liushucheng@huawei.com


   Jianping Sun
   China Telecom
   NO 1835, Dongnan RD, Pudong DIST
   Shanghai,
   China

   Email: sunjp@sttri.com.cn
























Zhang, et al.           Expires January 17, 2013                [Page 8]