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]