TRILL: ARP/ND Optimization
draft-yizhou-trill-arp-optimization-00

TRILL Working Group                                            Yizhou Li
INTERNET-DRAFT                                           Donald Eastlake
Intended Status: Standard Track                             Linda Dunbar
                                                     Huawei Technologies
                                                           Radia Perlman
                                                                     EMC
                                                          Igor Gashinsky
                                                                   Yahoo
Expires: April 30, 2015                                 October 27, 2014

                       TRILL: ARP/ND Optimization
                 draft-yizhou-trill-arp-optimization-00

Abstract

   This document describes mechanisms to optimize the ARP (Address
   Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
   campus. Such optimization reduces the flooding over campus. 

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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/1id-abstracts.html

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

Copyright and License Notice

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

Yizhou, et al                                                   [Page 1]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

   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
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   2 IP/MAC address mappings  . . . . . . . . . . . . . . . . . . . .  3
   3. Handling ARP/ND messages  . . . . . . . . . . . . . . . . . . .  4
     3.1 Get the mapping information of the sender's IP and MAC for
         non-zero IP. . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2 Determine how to reply the ARP/ND request. . . . . . . . . .  5
     3.3 Determine how to handle the ARP/ND response. . . . . . . . .  6
   4. Handling RARP (Reverse Address Resolution Protocol) messages  .  6
   5 Security Considerations  . . . . . . . . . . . . . . . . . . . .  6
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     5.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  8

 

Yizhou, et al                                                   [Page 2]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

1 Introduction

   IEEE 802.1 bridges forward an ARP/ND query as an ordinary
   broadcast/multicast frame to all links belonging to the same VLAN. 
   RBridges May implement an "optimized ARP/ND response" when the
   target's location is assumed to be known by the ingress RBridge.
   ARP/ND query flooding can be avoided.

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

   The acronyms and terminology in [RFC6325] is used herein with the
   following additions:

   TRILL switch - an alternative term for an RBridge.

2 IP/MAC address mappings

   Traditionally an RBridge learns the MAC and nickname correspondence
   of a remote host as per [RFC6325] from TRILL data frame received. No
   IP address information is learned directly from the TRILL data frame.
   Interface Addresses (IA) APPsub-TLV [IA] enhanced TRILL base protocol
   by allowing IP and MAC address mappings to be distributed at the
   control plane by any RBridge. This APPsub-TLV appears inside the
   TRILL GENINFO TLV specified in ESADI [RFC7357] but may also occur in
   other application contexts. Edge Directory Assist Mechanisms
   [DirMech] makes use of this APPsub-TLV too for its push model.  

   An RBridge can easily know the IP/MAC address mappings of the hosts
   in the local network that is attached to it via the access ports by
   receiving the ARP [RFC826] or ND [RFC4861] messages. If the RBridge
   has not saved sender's IP/MAC address pair in the received data
   packet, it may save the information and use Interface Addresses
   APPsub-TLV distribute them to other RBridges. Then the relevant
   remote RBridges (normally those attached by hosts from the same Data
   Label as the original ARP/ND messages) receives and saves such
   mapping information too. There are others ways that RBridges saves
   IP/MAC address mappings in advance, e.g. import from management
   system and distribution by directory servers [DirMech]. 

   The examples given above show that RBridges may have saved a host's
   triplet of {IP address, MAC address, ingress nickname} for a given
 

Yizhou, et al                                                   [Page 3]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

   Data Label (VLAN or FGL) before that host sends or receives any real
   data packet. Note such information may or may not be a complete list
   and may or may not exist on all RBridges. Information are possibly
   from different sources. RBridges can use Flags Field in APPsub-TLV to
   identify if the source is directory server or local observation by
   the sender. Different confidence level may also be used to indicate
   the reliability of the mapping information.  

3. Handling ARP/ND messages

   ARP [RFC826] message is detected by its Ethertype of 0x0806. ND
   [RFC4861] defines five different ICMPv6 packet types. ARP/ND is
   commonly used on a link to (1) query for the MAC address
   corresponding to an IPv4 address, (2) test if an IPv4/IPv6 address is
   already in use, or (3) to announce the new or updated info on any of
   IPv4/IPv6 address, MAC address, and/or point of attachment.  

   To simplify the text, we use the following terms in this section.

   IP address - indicated protocol address which is normally IPv4
   address in ARP, IPv6 address in ND sender's IP/MAC address - sender
   protocol/hardware address in ARP, source IP address and source link-
   layer address in ND target's IP/MAC address - target
   protocol/hardware address in ARP, target address and target link-
   layer address in ND 

   When an ingress RBridge receives an ARP/ND message, it can perform
   the following steps described in sub-sections.

3.1 Get the mapping information of the sender's IP and MAC for non-zero
   IP.

   If the information of the sender's MAC has not been saved by the
   ingress RBridge before, populate the information of sender's IP/MAC
   to its ARP table;

   else if the sender's MAC has been saved before however with a
   different IP address mapped, the RBridge should verify if a duplicate
   IP address has already been in use. The RBridge may take different
   strategies to do so, for example, ask the authoritative entity like
   directory servers or encapsulate and unicast the ARP/ND message to
   the location where it believes a duplicate address is in use.

   The ingress RBridge may use IA APPsub-TLV [IA] with the Local flag
   set in ESADI [RFC7357] to distribute any new or updated IP/MAC
   information obtained in this step. If push directory server is used,
   such information can be distributed as per [DirMech].

 

Yizhou, et al                                                   [Page 4]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

3.2 Determine how to reply the ARP/ND request.

   a) If the message is a generic ARP/ND request and the ingress RBridge
   knows target's IP address, the ingress RBridge may decide to take one
   or combination of the following actions: 

   1. send an ARP/ND response directly to the querier, with the target's
   MAC address, as believed by the ingress RBridge 

   2. encapsulate the ARP/ND request to the target's Designated RBridge,
   and have the Designated RBridge at the target forward the query to
   the target. This behavior has the advantage that a response to the
   request is authoritative. If the request does not reach the target,
   then the querier does not get a response 

   3. block ARP/ND requests that occur for some time after a request to
   the same target has been launched, and then respond to the querier
   when the response to the recently-launched query to that target is
   received

   4. pull the most up-to-date records if pull directory server is in
   use [DirMech] and reply to the querier

   5. flood the request as per RFC6325

   b) If the message is a generic ARP request and the ingress RBridge
   does not know target's IP address, the ingress RBridge may take one
   of the following actions.

   1. flood the message as per RFC6325

   2. use directory server to pull the information [DirMech] and reply
   to the querier

   3. drop the message

   c) If the message is a gratuitous ARP which can be identified by the
   same sender's and target's "protocol" address fields or an
   Unsolicited Neighbor Advertisements [RFC4861] in ND:

   The RBridge may use IA APPsub-TLV [IA] with the Local flag set to
   distribute the sender's MAC and IP mapping information. When
   directory server is deployed and complete Push Directory information
   is used by all the TRILL switches in the Data Label, gratuitous ARP
   or unsolicited NA SHOULD be discarded rather than ingressed.
   Otherwise, they are either ingressed and flooded as per RFC6325 or
   discarded depending on local policy.

 

Yizhou, et al                                                   [Page 5]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

   d) If the message is a Address Probe ARP Query [RFC5227] which can be
   identified by the sender's protocol (IPv4) address field being zero
   and the target's protocol address field being the IPv4 address to be
   tested or a Neighbor Solicitation for DAD (Duplicate Address
   Detection) which has unspecified source address [RFC4862]: it should
   be handled as the generic ARP message as in a) and b).

   It should be noted in the case of secure neighbor discovery (SEND)
   [RFC3971], cryptography might prevent local reply by the ingress
   RBridge, since the RBridge would not be able to sign the response
   with the target's private key. 

   It is not essential that all RBridges use the same strategy for which
   option to select for a particular ARP/ND query. It is up to the
   implementation.

3.3 Determine how to handle the ARP/ND response.

   If the ingress RBridge R1 decides to unicast the ARP/ND request to
   the target's Designated RBridge R2 as shown in subsection 3.2 item a
   or to flood the request as per RFC6325, then R2 decapsulates the
   query, and initiate an ARP/ND query on the target's link. When/if the
   target responds, R2 encapsulates and unicast the response to R1,
   which decapsulates the response and send it to the querier. R2 should
   initiates a link state update to inform all the other RBridges of the
   target's location, layer 3 address, and layer 2 address, in addition
   to forwarding the reply to the querier. The update message can be
   carried by IA APPsub-TLV [IA] with the Local flag set in ESADI
   [RFC7357] or as per [DirMech] if push directory server is in use. 

4. Handling RARP (Reverse Address Resolution Protocol) messages

   RARP [RFC903] uses the same packet format as ARP but a different
   Ethertype (0x8035) and opcode values. Its use is similar to the
   generic ARP Request/Response as described in 3.2 a) and b).  The
   difference is that it is intended to query for the target "protocol"
   address corresponding to the target "hardware" address provided.  It
   should be handled by doing a local cache or directory server lookup
   on the target "hardware" address provided to find a mapping to the
   desired "protocol" address. Normally, look up a MAC address to find
   the corresponding IP address.

5 Security Considerations

   ARP and ND messages can be easily forged. Therefore the learning of
   MAC/IP addresses from them should not be considered as reliable.
   RBridge can use the confidence level in received IA APPsub-TLV to
   determine the reliability of MAC/IP address mapping. It is up to the
 

Yizhou, et al                                                   [Page 6]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

   implementation to decide if an RBridge should distribute the IP and
   MAC address mappings received from ARP/ND to other RBridges in the
   same VLAN/FGL.

   The ingress RBridge should also rate limit the ARP/ND queries for the
   same target to be injected to the TRILL campus prevent the possible
   attack.

6  IANA Considerations

   No IANA action is required. RFC Editor: please delete this section
   before publication.

6  References

5.1  Normative References

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

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

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC
              826, November 1982.

   [RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
              Reverse Address Resolution Protocol", STD 38, RFC 903,
              June 1984

   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", RFC 6165, April 2011.

   [RFC6325] Perlman, R., et.al. "RBridge: Base Protocol Specification",
              RFC 6325, July 2011.

   [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and
              A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis-
              rfc6326bis, work in progress.

   [RFC6327bis] Eastlake 3rd, D., R. Perlman, A. Ghanwani, H. Yang, and
 

Yizhou, et al                                                   [Page 7]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

              V. Manral, "TRILL: Adjacency", draft-ietf-trill-
              rfc6327bis, work in progress.

   [RFC6439] Eastlake, D. et.al., "RBridge: Appointed Forwarder", RFC 
              6439, November 2011.

5.2  Informative References

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

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

   [RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
              Gashinsky, "Directory Assistance Problem and High-Level
              Design Proposal", RFC 7067, November 2013.

   [IA] Eastlake, D., Li Y., R. Perlman, "TRILL: Interface Addresses
              APPsub-TLV", draft-eastlake-trill-ia-appsubtlv, work in
              progress.

   [DirMech] Dunbar, L., Eastlake 3rd, D., Perlman, R., I. Gashinsky.
              and Li Y., TRILL: Edge Directory Assist Mechanisms",
              draft-ietf-trill-directory-assist-mechanisms, work in
              progress.

Authors' Addresses

   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China

   Phone: +86-25-56625375
   EMail: liyizhou@huawei.com

   Donald Eastlake
   Huawei R&D USA
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

 

Yizhou, et al                                                   [Page 8]
INTERNET DRAFT    Problems of Active-Active connection         July 2013

   Linda Dunbar
   Huawei Technologies
   5430 Legacy Drive, Suite #175
   Plano, TX 75024, USA

   Phone: +1-469-277-5840
   EMail: ldunbar@huawei.com

   Radia Perlman
   EMC
   2010 256th Avenue NE, #200
   Bellevue, WA 98007
   USA

   Email: Radia@alum.mit.edu

   Igor Gashinsky
   Yahoo
   45 West 18th Street 6th floor
   New York, NY 10011 USA

   EMail: igor@yahoo-inc.com

Yizhou, et al                                                   [Page 9]