One document matched: draft-lin-savi-roaming-nd-00.txt




SAVI                                                         T. Lin, Ed.
Internet Draft                              Hangzhou H3C Tech. Co., Ltd.
Intended status: Standard Tracks
Expires: April 15, 2011                                 October 15, 2010


                      Roaming over SAVI devices  
                     draft-lin-savi-roaming-nd-00 

Abstract 

   This document specifies the procedure for roaming over devices that
   implemented SAVI (Source Address Validation Improvements) device. 
   The binding entry creating by NDP snooping can be synchronized by
   some mechanism.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before October 10,
   2010. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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



Lin                     Expires April 15, 2011                  [Page 1]

Internet-Draft                savi-roaming                  October 2010


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 15, 2011.

Copyright Notice

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

   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


   Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1
   Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . .  2
   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Conventions used in this document . . . . . . . . . . . . . . .  3
   3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . .  3
   5. Solution for roaming over devices . . . . . . . . . . . . . . .  5
      5.1. Binding entry establishing . . . . . . . . . . . . . . . .  5
      5.2. Binding entry moving . . . . . . . . . . . . . . . . . . .  5
      5.2. Source address selection . . . . . . . . . . . . . . . . .  6
   6. Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   8. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
      8.1. Normative References . . . . . . . . . . . . . . . . . . .  6
      8.2. Informative References . . . . . . . . . . . . . . . . . .  6
   9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  7
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  7











Lin                     Expires April 15, 2011                  [Page 2]

Internet-Draft                savi-roaming                  October 2010


1. Introduction

   This document specifies the procedure for roaming over devices that
   implemented SAVI (Source Address Validation Improvements) device. 
   The binding entry creating by NDP snooping can be synchronized by
   some mechanism.

   There is a mechanism which designed to provide a host level source IP
   address validation granularity([I-D.bi-savi-stateless]), which 
   includes NDP/ARP snooping to set up bindings between stateless IP 
   addresses and corresponding anchors. The bindings can be used to
   validate the source address in the packets. This mechanism is
   deployed on access device(we mainly talk about access switch), named
   SAVI devices.

   The NDP/ARP snooping mechanism in SAVI devices snoop the NDP/ARP
   packets to establish the corresponding binding entry of the host,
   which includes IP address, MAC address, VLAN, port, etc.
   
   The binding entry can filter packets with forged IP addresses,
   including NDP/ARP packet and common data packet. 
   [I-D.ietf-savi-framework-00] describes this filtering precedure.

   This mechanism can nicely filter packets on a SAVI device in one
   access device LAN. If there is two or more SAVI devices, if the host
   roams from one SAVI device to another SAVI device, the following
   issues must be considered: How to aging the binding entry on the
   first SAVI device, and how to defend the forged host while the real
   host can roaming correctly.


2. Conventions used in this document

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

3. Terminology

   Uplink port: The up link port of the access switch. SAVI device is a
                access device, so the snooping and filtering should aim
                at the port connected to user. NDP/ARP snooping can omit
                the learning procedure of binding entry.

4. Problem Statement

   As shown in figure 1, two switches are connected one aggregation
   device (AGG). If one host connects to SWB(Switch B), the



Lin                     Expires April 15, 2011                  [Page 3]

Internet-Draft                savi-roaming                  October 2010


   corresponding binding entry will be established in SWB. When this
   host roams to SWA(Switch A), all involved ports's link state will
   changed, so the corresponding binding entry can established in SWA. 
   But SWB's entry won't be removed immediately. 
 
   The following is the processes:

   1) When the host is removed from SWB, SWB will keep the binding entry
      for a while.

   2) When the host is connected SWA, the link state of the host's net
      card interface will turn up, so the host will send DAD NS.

   3) When SWA receive this packet, it find this is a new host connected
      to it. SWA will establish a new binding entry, and forward this
      packet.

   4) When SWB receives this packet, because the received port is uplink 
      port, so it only forward it.

   5) Because there isn't any host connect the SWB's port which the host
      connected formerly, so this packet will be discarded finally.

   Now, there are two binding entries of one host in two SAVI devices, 
   this is a very confusable condition.

   From the above, the key element of the roaming over SAVI devices is
   uplink port. If the binding entries can be established in this port,
   the roaming can successfully process, but all the SAVI devices will
   have all the host corresponding binding entries. These is a huge
   resource waste.

                                 +---------+
                  +--------------+   AGG   +--------------+
                  |              +---------+              |
                  |                                       |
             +----+----+                             +----+----+
             |   SWA   |                             |   SWB   |
             +----+----+                             +----+----+
                  |                                       |
                  |                                       |
             +----+----+                             +----+----+
             |  HostA  |                             |  HostB  |
             +---------+                             +---------+
                         Figure 1 Roaming over devices






Lin                     Expires April 15, 2011                  [Page 4]

Internet-Draft                savi-roaming                  October 2010


5. Solution for roaming over devices

   Considering the uplink port snooping, the SAVI device can know the
   host connected others SAVI device, this is a key to promote the
   roaming.
   
   Based on the uplink port, the following procedure is proposed to
   deal with the issue in section 4, the host can roam over SAVI devices.

5.1.  Binding entry establishing

   When the host connects to SWB, the normal binding entry establishing
   procedure([I-D.bi-savi-stateless]) is process in SWB. The DAD NS
   also forward to SWA transit AGG, SWA's uplink port will received this
   packet.

   But SWA must ignore this packet, not to established any binding entry
   to avoid the huge binding table.

5.2.  Binding entry moving

   When the host is roaming to SWA, the following processes happen:

   1) When the host is removed from SWB, SWB will keep the binding entry
      for a while.

   2) When the host is connected SWA, the link state of the host's net
      card interface will turn up, so the host will send DAD NS.

   3) When SWA receive this packet, it find this is a new host connected
      to it. SWA will establish a new binding entry, and forward this
      packet.

   4) When SWB receives this packet, it will analysis this packet as
      normal NDP snooping, so as to find there is a binding entry
      correspond to that host,  only the input port is uplink port.

   5) According this binding entry, SWB sending a normal NS through the
      original port the host connected to probe if or not the host is
      still connected here. Because the host is removed from SWB, so SWB
      can't received any response. 

   6) Then SWB sends a normal NS through the uplink port to probe if
      there is a new host connected other switch. SWA can receive this
      packet and forward it to the host, and the host will respond to
      SWB.





Lin                     Expires April 15, 2011                  [Page 5]

Internet-Draft                savi-roaming                  October 2010


   7) When SWB receives this responding packet, it will remove that
      corresponding binding entry. Because this packet is received in
      uplink port from other switch, SWB can know that other switch have
      established a binding entry of this packet. 

   Now the host have successfully roaming from SWB to SWA, and SWB have
   not the host's corresponding binding entry.

5.3.  Source address selection

   In the process 5) and 6), SWB needs to send a NS packet which source
   IP address must be SWB's IP address. Otherwise, the response packet
   may not be received by SWB, and this mechanism will not take effect.

6. Security Considerations

   There is no security consideration currently.

7. IANA Considerations

   There is no IANA consideration currently.

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

   [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
   March 1997.

   [RFC3307] B. Haberman, "Allocation Guidelines for IPv6 Multicast
   Addresses", RFC3307, August 2002.

   [RFC3315] R. Droms, Ed. "Dynamic Host Configuration Protocol for IPv6
   (DHCPv6)", RFC3315, July 2003.

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

   [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless
   Autoconfiguration", RFC4862,   October, 2007.

   [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227,
   July 2008.



Lin                     Expires April 15, 2011                  [Page 6]

Internet-Draft                savi-roaming                  October 2010


   [I-D.ietf-savi-framework-00]
              J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt,  "Source
              Address Validation Improvement Protocol Framework",
              I-D.ietf-savi-framework-00(work in progress),   October
              2010.

   [I-D.bi-savi-stateless]
              J. Bi, G. Yao, J. Wu, and F. Baker, "SAVI Solution for
              Stateless Address", I-D.bi-savi-stateless-00 (work in
              progress), April 2010.

9. Acknowledgments

Thanks to Zhenglin Qi, Daogui Liu, Cong Xue, Lei Cao, Li Hou, Jun Bi,
and Guang Yao for their valuable contributions.

Authors' Addresses

   Tao Lin
   Hangzhou H3C Tech. Co., Ltd.
   Beijing R&D Center of H3C, Digital Technology Plaza
   NO. 9 Shangdi 9th Street, Haidian District
   Beijing  100085
   China

   Phone: +86 010 82774704
   EMail: lintaog@gmail.com
























Lin                     Expires April 15, 2011                  [Page 7]



PAFTECH AB 2003-20262026-04-23 08:07:46