IPv6 Maintenance WG H. Li Internet-Draft Y. Li Intended status: Standards Track Huawei Technologies Expires: January 7, 2010 July 6, 2009 Line identification in IPv6 Neighbour Solicitation messages draft-li-6man-ns-mark-00 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/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 January 7, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Li & Li Expires January 7, 2010 [Page 1] Internet-Draft Line identification in NS July 2009 Abstract Duplicate address detection of link-local address in DSL access network is a mandatory part for IPv6 netwrok. In N:1 VLAN model, simple DAD does not work due to the user isolation. NAS should perform a DAD proxy function for the task. This documents proposes to include the line identification information in neighbour solicitation and neighbour advertisement messages to help DAD proxy to perform the function. Li & Li Expires January 7, 2010 [Page 2] Internet-Draft Line identification in NS July 2009 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Line Identification Neighbor Discovery Option . . . . . . . . 6 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Upstream neighbour solicitation . . . . . . . . . . . . . 7 4.2. Downstream neighbour advertisement . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Li & Li Expires January 7, 2010 [Page 3] Internet-Draft Line identification in NS July 2009 1. Introduction In widely deployed DSL access network, Figure 1 shows a common architecture which was described in [TR-101]. Although [TR-101] focuses on the IPv4 based access architecture, IPv6 based access need as well a similar network topology and functionalities for smooth migration from or co-existence with IPv4. In a DSL access network, there exists many-to-one mapping relationship between user ports and VLAN, which is called N:1 VLAN model as defined in [TR-101]. User ports may be located in the same or different Access Nodes. It is noted, unlike in 1:1 VLAN model which indicates a one-to-one mapping between user port and VLAN, performing routine IPv6 operations in N:1 VLAN model needs further consideration. For example, duplicate address detection (DAD) is necessary but it can't be performed in the same way as defined in [RFC4862], as user ports are isolated on Layer 2 in a same N:1 VLAN. This document proposes a method of using line id information in neighbour solicitation and neighbour advertisement messages to help performing DAD in N:1 VLAN model in an IPv6 based access network. +----+ +------+ Home ---|HGW1|---| | Network +----+ |Access|\ | Node1| \ +----+ | | \ Home ---|HGW2|---| | \+-----------+ +-----+ Network +----+ +------+ | | | | |Aggregation|--| NAS | | Node | | | +----+ +------+ /+-----------+ +-----+ Home ---|HGW3|---| | / Network +----+ |Access| / | Node2|/ +----+ | | Home ---|HGW4|---| | Network +----+ +------+ Figure 1: DSL Network Architecture Li & Li Expires January 7, 2010 [Page 4] Internet-Draft Line identification in NS July 2009 2. Problem Statement A fixed broadband network access is a NBMA (non-broadcast multiple access) network. Access Nodes must be able to prevent forwarding traffic between user ports, which enables Layer 2 isolation of users. This "split-horizon" forwarding prevents users from seeing each other's traffic. IPv6 ND (neighbour discovery) [RFC4861] messages, like Neighbor Solicitation and Router Solicitation, sent by a HGW or a terminal in a home network are forwarded to NAS but not allowed to be directly forwarded to other HGWs by Access Node. DAD mechanism [RFC4862] uses NS/NA messages to check if there are duplicated addresses in a same VLAN. In N:1 VLAN model, a Link-local address of a HGW WAN interface should go through DAD procedures before it becomes effective. However, such procedures have difficulty to be implemented due to split-horizon forwarding mechanism. To overcome the DAD difficulty in N:1 VLAN model in the broadband access network, it was proposed and has been consented that NAS, the IP edge device, needs to implement a DAD proxy function by Broadband Forum in a conference call in June 2009. DAD proxy caches the binding of LLA, MAC and/or port number. Upstream NS for a tentative link-local address DAD is captured by DAD proxy. DAD proxy checks if any other MAC or port has been bound to the tentative LLA. If such binding has been found, DAD proxy replies with NA for DAD; if not, DAD proxy caches the binding and does not reply with NA. NS for DAD uses the unspecified address as source IP and the solicited-node multicast address of the target address as destination IP. If a duplicate address is found, NAS sends back NA with the tentative LLA address as source IP and all-nodes multicast address as destination IP. As there are multiple ANs aggregated to a single NAS interface, downstream multicast NA may cause multicast storms and bring security issues as it discloses the binding information to those irrelevant access ports. In order to make sure NA being only forwarded to the sender of DAD NS message, this draft proposes to add line id information in NS/NA for DAD procedures. Li & Li Expires January 7, 2010 [Page 5] Internet-Draft Line identification in NS July 2009 3. Line Identification Neighbor Discovery Option A new option was proposed to carry line identification in IPv6 Router Solicitation messages[I-D.krishnan-6man-rs-mark]. This new LIO option was proposed to be added into RS/RA messages with the following format. In this document, we re-use this option and allow it to be inserted into NS/NA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Line Identification... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Line Identification Option Type: 8-bit identifier of the type of option. To be determined by IANA Length: 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Line Identification: In a Neighbour Solicitation: Variable length data inserted by the Access Node describing the subscriber agent circuit identifier corresponding to the logical access loop port of the Access Node from which the NS was initiated. In a Neighbour Advertisement: Variable length data inserted by NAS describing the subscriber agent circuit identifier corresponding to the logical access loop port of the Access Node on which the NA needs to be sent out. Li & Li Expires January 7, 2010 [Page 6] Internet-Draft Line identification in NS July 2009 4. Operations 4.1. Upstream neighbour solicitation When HGW WAN interface sends an NS for LLA DAD, AN receives it on a particular access line. AN then inserts an LIO option into NS message. The line identification field in LIO should be set to a unique value of logical access loop port of the Access Node from which the NS was received. Neighbour solicitation with LIO is then forwarded to NAS by AN. When NAS receives an NS, it checks if the source IP is the unspecified IP address. If it is, the received NS is for DAD purpose and such NS is referred as NS-DAD in this document. DAD proxy in NAS checks if the tentative LLA in Target Address field has already bound to another MAC or another access port. LIO information MUST be presented in NS if DAD proxy is required to check the binding relationship based on the line ID information. If binding exists, it implies there is a duplicated address and DAD proxy should response with NA; otherwise, DAD proxy puts the new binding information to its cache. If the binding information includes the line identification, DAD proxy SHOULD check for the LIO option for line identification other than LLA and MAC. 4.2. Downstream neighbour advertisement On receiving a NS-DAD, if a duplicate address is found in DAD-proxy's cache, a responding NA should be sent. The source address is the tentative LLA in the received NS and the destination address is all- nodes multicast address. As it is a multicast message, LIO information should be included in downstream NA sent from NAS to help AN unicast the packet to the right NS-DAD sender. The LIO option value MUST be set to the same value as was received in the LIO option of the NS. When AN receives NA from NAS with LIO information, AN MUST forward it downstream based on the value of the Line Identification field of the option even the IP destination is a multicast address and AN MUST remove the option before forwarding the NA to the subscriber premise. Li & Li Expires January 7, 2010 [Page 7] Internet-Draft Line identification in NS July 2009 5. Security Considerations LIO information is not securely protected. As fixed broadband access network usually is a trusted network, it can be expected that LIO information inserted by AN is trustful. In addition, if SeND [RFC3971] is used, LIO information insertion by AN would not work. Li & Li Expires January 7, 2010 [Page 8] Internet-Draft Line identification in NS July 2009 6. IANA Considerations This document can re-use the LIO option defined in Line identification in IPv6 Router Solicitation messages [I-D.krishnan-6man-rs-mark]. Li & Li Expires January 7, 2010 [Page 9] Internet-Draft Line identification in NS July 2009 7. References 7.1. Normative Reference [I-D.krishnan-6man-rs-mark] Krishnan, S., Kavanagh, A., Ooghe, S., and B. Varga, "Line identification in IPv6 Router Solicitation messages", draft-krishnan-6man-rs-mark-02 (work in progress), March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [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. [TR-059] DSL Forum, "DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services", TR 059, September 2003. [TR-101] DSL Forum, "Migration to Ethernet Based DSL Aggregation", TR 101, April 2006. Li & Li Expires January 7, 2010 [Page 10] Internet-Draft Line identification in NS July 2009 Authors' Addresses Hongyu Li Huawei Technologies Huawei Industrial Base Shenzhen, 518129 China Phone: +86-755-28973567 Fax: Email: lihy@huawei.com URI: Yizhou Li Huawei Technologies Huihong Mansion, No. 91 Baixia Rd Nanjing, 210001 China Phone: +86-25-84565887 Fax: Email: liyizhou@huawei.com URI: Li & Li Expires January 7, 2010 [Page 11]