--- 1/draft-nordmark-intarea-ippl-02.txt 2016-03-21 11:22:43.262499090 -0700 +++ 2/draft-nordmark-intarea-ippl-03.txt 2016-03-21 11:22:43.342501092 -0700 @@ -1,18 +1,18 @@ INTAREA E. Nordmark Internet-Draft Arista Networks -Intended status: Standards Track Oct 2015 -Expires: April 3, 2016 +Intended status: Standards Track Mar 2016 +Expires: September 2, 2016 IP over Intentionally Partially Partitioned Links - draft-nordmark-intarea-ippl-02 + draft-nordmark-intarea-ippl-03 Abstract IP makes certain assumptions about the L2 forwarding behavior of a multi-access IP link. However, there are several forms of intentional partitioning of links ranging from split-horizon to Private VLANs that violate some of those assumptions. This document specifies that link behavior and how IP handles links with those properties. @@ -24,54 +24,55 @@ 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 April 3, 2016. + This Internet-Draft will expire on September 2, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Keywords and Terminology . . . . . . . . . . . . . . . . . . . 3 3. Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Bridge Behavior . . . . . . . . . . . . . . . . . . . . . 4 4. IP over IPPL . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IPv6 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . . 8 8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 8 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction IPv4 and IPv6 can in general handle two forms of links; point-to- point links when only have two IP nodes (self and remote), and multi- access links with one or more nodes attached to the link. For the multi-access links IP in general, and particular protocols like ARP and IPv6 Neighbor Discovery, makes a few assumptions about transitive and reflexive connectivity i.e., that all nodes attached to the link can send packets to all other nodes. @@ -214,34 +215,49 @@ L-flag (on-link) to zero for all of the Prefix Information options. Note that this is orthogonal to whether SLAAC (Stateless Address Auto-Configuration) [RFC4862] or DHCPv6 [RFC3315] is used for address autoconfiguration. Setting the L-flag to zero is RECOMMENDED configuration for private VLANs. If the policy includes allowing some packets that are sent to link- local destinations to cross between different tenants, then some for of NS/NA proxy is needed in the routers, and the routers need to forward packets addressed to link-local destinations out the same - interface as REQUIRED in [RFC2460]. However, the necessary NS/NA - proxy would be non-trivial since there can be multiple promiscuous - ports hence multiple routers thus a risk of a NS being proxied in a - loop going back out on the same link. Hence a NS/NA proxy MUST NOT - be used with private VLANs. + interface as REQUIRED in [RFC2460]. If the policy allows for some + packets sent to global IPv6 address to cross between tenants then the + routers would forward such packets out the same interface. However, + with the L=0 setting those global packets will be sent to the default + router, while the link-local destinations would result in a Neighbor + Solicitation to resolve the IPv6 to link-layer address binding. + Handling such a NS when there are multiple promiscuous ports hence + multiple routers risks creating loops. If the router already has a + neighbor cache entry for the destination it can respond with an NA on + behalf of the destination. However, if it does not it MUST NOT send + a NS on the link, since the NA will be received by the other + router(s) on the link which can cause an unbounded flood of multicast + NS packets (all with hoplimit 255), in particular of the host IPv6 + address does not respond. Note that such an NS/NA proxy is defined + in [RFC4389] under some topological assumptions such as there being a + distinct upstream and downstream direction, which is not the case of + two or more peer routers on the same IPPL. For that reason NS/NA + packet proxies as in [RFC4389] MUST NOT be used with IPPL. IPv6 includes Duplicate Address Detection [RFC4862], which assumes that a link-local IPv6 multicast can be received by all hosts which share the same subnet prefix. That is not the case in a private VLAN, hence there could potentially be undetected duplicate IPv6 addresses. However, the DAD proxy approach [RFC6957] defined for split-horizon behavior can safely be used even when there are multiple promiscuous ports hence multiple routers attached to the - link. The use of [RFC6957] with private VLAN is RECOMMENDED. + link, since it does not rely on sending Neighbor Solicitations + instead merely gathers state from received packets. The use of + [RFC6957] with private VLAN is RECOMMENDED. The Router Advertisements in a private VLAN MUST be sent out on a promiscuous VLAN ID so that all nodes on the link receive them. 6. IPv4 over IPPL IPv4 [RFC0791] and ARP [RFC0826] do not have a counterpart to the Neighbor Discovery On-link flag. Hence nodes attached to isolated or community ports will always ARP for any destination which is part of its configured subnet prefix, and those ARP request packets will not @@ -293,22 +309,22 @@ In addition to the above issues when multiple routers are attached to the same PVLAN, the routers need to avoid potential routing loops for packets entering the subnet. When such a packet arrives the router might need to send a ARP request (or Neighbor Solicitation) for the host, which can trigger the other router to send a proxy ARP (or Neighbor Advertisement). The host, if present, will also respond to the ARP/NS. This issue is described in [PVLAN-HOSTING] in the particular case of HSRP. When multiple routers are attached to the same PVLAN, wheter they are - using VRRP, HSRP, or neither, they MUST NOT proxy ARP/ND respond to a - request from another router. At a minimum a router MUST be + using VRRP, HSRP, or neither, they SHOULD NOT proxy ARP/ND respond to + a request from another router. At a minimum a router MUST be configurable with a list of IP addresses to which it should not proxy respond. Thus the user can configure that list with the IP address(es) of the other router(s) attached to the PVLAN. 8. Multicast over IPPL Layer 2 multicast or broadcast is used by protocols like ARP [RFC0826], IPv6 Neighbor Discovery [RFC4861] and Multicast DNS [RFC6762] with link-local scope. The first two have been discussed above. @@ -336,22 +352,28 @@ In general DAD is subject to a Denial of Service attack since a malicious host can claim all the IPv6 addresses [RFC3756]. Same issue applies to IPv4/ARP when Address Conflict Detection [RFC5227] is implemented. 10. IANA Considerations There are no IANA actions needed for this document. -11. References -11.1. Normative References +11. Acknowledgements + + The author is grateful for the comments from Mikael Abrahamsson, Fred + Baker, Wes Beebee, Hemant Singh, Dave Thaler, and Sowmini Varadhan. + +12. References + +12.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, . @@ -373,48 +395,52 @@ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/ RFC4862, September 2007, . [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, "Duplicate Address Detection Proxy", RFC 6957, DOI 10.17487/RFC6957, June 2013, . -11.2. Informative References +12.2. Informative References [DOCSIS-MULPI] "DOCSIS 3.0: MAC and Upper Layer Protocols Interface Specification", August 2015, . [I-D.ietf-dnssd-hybrid] Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service - Discovery", draft-ietf-dnssd-hybrid-00 (work in progress), - November 2014. + Discovery", draft-ietf-dnssd-hybrid-03 (work in progress), + February 2016. [PVLAN-HOSTING] "PVLANs in a Hosting Environment", March 2010, . [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, . + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery + Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, + April 2006, . + [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, DOI 10.17487/RFC4562, June 2006, . [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008, . [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private