[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-intarea-ippl

INTAREA                                                      E. Nordmark
Internet-Draft                                           Arista Networks
Intended status: Standards Track                            July 7, 2015
Expires: January 8, 2016


           IP over Intentionally Partially Partitioned Links
                     draft-nordmark-intarea-ippl-00

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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 January 8, 2016.

Copyright Notice

   Copyright (c) 2015 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



Nordmark                 Expires January 8, 2016                [Page 1]


Internet-Draft                    IPPL                         July 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  IPv4 over IPPL  . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9
































Nordmark                 Expires January 8, 2016                [Page 2]


Internet-Draft                    IPPL                         July 2015


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.

   There are cases where for various reasons and deployments one wants
   what looks like one link from the perspective of IP and routing, yet
   the L2 connectivity is restrictive.  A key property is that an IP
   subnet prefix is assigned to the link, and IP routing sees it as a
   regular multi-access link.  But a host attached to the link might not
   be able to send packets to all other hosts attached to the link.  The
   motivation for this is outside the scope of this document, but in
   summary the motivation to preserve the subnet view as seen by IP
   routing is to conserve IP(v4) address space, and the motivation to
   restrict communication on the link could be due to (security) policy
   or potentially wireless connectivity approaches.

   This intentional and partial partition appears in a few different
   forms.  For DSL [TR-101] and Cable [Reference needed] the pattern is
   to have a single access router on the link, and all the hosts can
   send and receive from the access router, but host-to-host
   communication is blocked.  A richer set of restrictions are possible
   for Private VLANs (PVLAN) [RFC5517], which has a notion of three
   different ports i.e. attachment points: isolated, community, and
   promiscuous.  Note that other techniques operate at L2/L3 boundary
   like [RFC4562] but those are out of scope for this document.

   The possible connectivity patterns for PVLAN appears to be a superset
   of the DSL and Cable use of split horizon, thus this document
   specifies the PVLAN behavior, shows the impact on IP/ARP/ND, and
   specifies how IP/ARP/ND must operate to work with PVLAN.

   If private VLANs, or the split horizon subset, has been configured at
   layer 2 for the purposes of IPv4 address conservation, then that
   layer 2 configuration will affect IPv6 even though IPv6 might not
   have the same need for address conservation.


2.  Keywords and Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].



Nordmark                 Expires January 8, 2016                [Page 3]


Internet-Draft                    IPPL                         July 2015


   The following terms from [RFC4861] are used without modifications:
   node           a device that implements IP.
   router         a node that forwards IP packets not explicitly
                  addressed to itself.
   host           any node that is not a router.
   link           a communication facility or medium over which nodes
                  can communicate at the link layer, i.e., the layer
                  immediately below IP.  Examples are Ethernets (simple
                  or bridged), PPP links, X.25, Frame Relay, or ATM
                  networks as well as Internet-layer (or higher-layer)
                  "tunnels", such as tunnels over IPv4 or IPv6 itself.
   interface      a node's attachment to a link.
   neighbors      nodes attached to the same link.

   This document defines the following set of terms:
   bridge         a layer-2 device which implements 802.1Q
   port           a bridge's attachment to another bridge or to a node.


3.  Private VLAN

   A private VLAN is a structure which uses two or more 802.1Q (VLAN)
   values to separate what would otherwise be a single VLAN, viewed by
   IP as a single broadcast domain, into different types of ports with
   different L2 forwarding behavior between the different ports.  A
   private VLAN consists of a single primary VLAN and multiple secondary
   VLANs.

   From the perspective of both a single bridge and a collection of
   interconnected bridges there are three different types of ports use
   to attach nodes plus an inter-bridge port:
   o  Promiscuous: A promiscuous port can send packets to all ports that
      are part of the private VLAN.  Such packets are sent using the
      primary VLAN ID.
   o  Isolated: Isolated VLAN ports can only send packets to promiscuous
      ports.  Such packets are sent using an isolated VLAN ID.
   o  Community: A community port is associated with a per-community
      VLAN ID, and can send packets to both ports in the same community
      VLAN and promiscuous ports.
   o  Inter-bridge: A port used to connect a bridge to another bridge.

3.1.  Bridge Behavior

   Once a bridge or a set of interconnected bridges have been configured
   with both the primary and isolated VLAN ID, and zero or more
   community VLAN IDs associated with the private VLAN, the following
   forward behaviors apply to the bridge:




Nordmark                 Expires January 8, 2016                [Page 4]


Internet-Draft                    IPPL                         July 2015


   o  A packet received on an isolated port MUST NOT be forwarded out an
      isolated or community port; it SHOULD (subject to bandwidth/
      resource issues) be forwarded out promiscuous and inter-bridge
      ports.
   o  A packet received on a community port MUST NOT be forwarded out an
      isolated port or a community port with a different VLAN ID; it
      SHOULD be forwarded out promiscuous and inter-bridge ports as well
      as community ports that have the same community VLAN ID.
   o  A packet received on a promiscuous port SHOULD be forwarded out
      all types of ports in the private VLAN.
   o  A packet received on an inter-bridge port with an isolated VLAN ID
      should be forwarded as a packet received on an isolated port.
   o  A packet received on an inter-bridge port with a community VLAN ID
      should be forwarded as a packet received on a community port
      associated with that VLAN ID.
   o  A packet received on an inter-bridge port with a promiscuous VLAN
      ID should be forwarded as a packet received on a promiscuous port.

   In addition to the above VLAN filtering and implied MAC address
   learning rules, the packet forwarding is also subject to the normal
   802.1Q rules with blocking ports due to spanning-tree protocol etc.


4.  IP over IPPL

   When IP is used over Intentionally Partially Partitioned links like
   private VLANs the normal usage is to attached routers (and
   potentially other shared resources like servers) to promiscuous
   ports, while attaching other hosts to either community or isolated
   ports.  If there is a single host for a given tenant or other domain
   of separation, then it is most efficient to attach that host to an
   isolated port.  If there are multiple hosts in the private VLAN that
   should be able to communicate at layer 2, then they should be
   assigned a common community VLAN ID and attached to ports with that
   VLAN ID.

   The above configuration means that hosts will not be able to
   communicate with each other unless they are in the same community.
   However, mechanisms outside of the scope of this document can be used
   to allow IP communication between such hosts e.g., by having firewall
   or gateway in or beyond the routers connected to the promiscuous
   ports.


5.  IPv6 over IPPL

   IPv6 Neighbor Discovery [RFC4861] can be used to get all the hosts on
   the link to send all unicast packets except those send to link-local



Nordmark                 Expires January 8, 2016                [Page 5]


Internet-Draft                    IPPL                         July 2015


   destination addresses to the routers.  That is done by setting the
   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.

   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.

   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
   be forwarded by the bridges to the target nodes.  Thus the routers
   attached to the promiscuous ports MUST provide a robust proxy ARP
   mechanism if they are to allow any (firewalled) communication between
   nodes from different tenants or separation domains.

   For the ARP proxy to be robust it MUST avoid loops where router1
   attached to the link sends an ARP request which is received by
   router2 (also attached to the link), resulting in an ARP request from
   router2 to be received by router1.  Likewise, it MUST avoids a
   similar loop involving IP packets, where the reception of an IP
   packet results in sending a ARP request from router1 which is proxied
   by router2.  At a minimum, the reception of an ARP request MUST NOT



Nordmark                 Expires January 8, 2016                [Page 6]


Internet-Draft                    IPPL                         July 2015


   result in sending an ARP request, and the routers MUST either be
   configured to know each others MAC addresses, or receive the VLAN
   tagged packets so they can avoid proxying when the packet is received
   on with the promiscuous VLAN ID.  Note that should there be an IP
   forwarding loop due to proxying back and forth, the IP TTL will
   expire avoiding unlimited loops.

   Any proxy ARP approach MUST work correctly with Address Conflict
   Detection [RFC5227].  ACD depends on ARP probes only receiving
   responses if there is a duplicate IP address, thus the ARP probes
   MUST NOT be proxied.  These ARP probes have a Sender Protocol Address
   of zero, hence they are easy to identify.

   When proxying an ARP request (with a non-zero Sender Protocol
   Address) the router needs to respond by placing its own MAC address
   in the Sender Hardware Address field.  When there are multiple
   routers attached to the private VLAN this will not only result in
   multiple ARP replies for each ARP request, those replies would have a
   different Sender Hardware Address.  That might seem surprising to the
   requesting node, but does not cause an issue with ARP implementations
   that follow the pseudo-code in [RFC0826].

   If the two or more routers attached to the private VLAN implement
   VRRP [RFC5798] the routers MAY use their VRRP MAC address as the
   Sender Hardware Address in the proxied ARP replies, since this
   reduces the risk nodes that do not follow the pseudo-code in
   [RFC0826].  However, if they do so it can cause flapping of the MAC
   tables in the bridges between the routers and the ARPing node.  Thus
   such use is NOT RECOMMENDED in general topologies of bridges but can
   be used when there are no intervening bridges.


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

   Multicast DNS can be handled by implementing using some proxy such as
   [I-D.ietf-dnssd-hybrid] but that is outside of the scope of this
   document.

   IP Multicast which spans across multiple IP links and that have
   senders that are on community or isolated ports require additional
   forwarding mechanisms in the routers that are attached to the
   promiscuous ports, since the routers need to forward such packets out
   to any allowed receivers in the private VLAN without resulting in



Nordmark                 Expires January 8, 2016                [Page 7]


Internet-Draft                    IPPL                         July 2015


   packet duplication.  For multicast senders on isolated ports such
   forwarding would result in the sender potentially receiving the
   packet it transmitted.  For multicast senders on community ports, any
   receivers in the same community VLAN are subject to receiving
   duplicate packets; one copy directly from layer 2 from the sender and
   a second copy forwarded by the multicast router.

   For that reason it is NOT RECOMMENDED to configure multicast
   forwarding from private VLANs.


8.  Security Considerations

   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.


9.  IANA Considerations

   There are no IANA actions needed for this document.


10.  References

10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              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, November 1982.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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



Nordmark                 Expires January 8, 2016                [Page 8]


Internet-Draft                    IPPL                         July 2015


   [RFC6957]  Costa, F., Combes, J-M., Pougnard, X., and H. Li,
              "Duplicate Address Detection Proxy", RFC 6957, June 2013.

10.2.  Informative References

   [I-D.ietf-dnssd-hybrid]
              Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
              Discovery", draft-ietf-dnssd-hybrid-00 (work in progress),
              November 2014.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.

   [RFC4562]  Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method
              for Subscriber Separation on an Ethernet Access Network",
              RFC 4562, June 2006.

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

   [RFC5517]  HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
              VLANs: Scalable Security in a Multi-Client Environment",
              RFC 5517, February 2010.

   [RFC5798]  Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
              Version 3 for IPv4 and IPv6", RFC 5798, March 2010.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              February 2013.

   [TR-101]   "Migration to Ethernet-Based DSL Aggregation", The
              Broadband Forum Technical Report TR-101, July 2011, <http:
              //www.broadband-forum.org/technical/download/
              TR-101_Issue-2.pdf>.












Nordmark                 Expires January 8, 2016                [Page 9]


Internet-Draft                    IPPL                         July 2015


Author's Address

   Erik Nordmark
   Arista Networks
   Santa Clara, CA
   USA

   Email: nordmark@arista.com











































Nordmark                 Expires January 8, 2016               [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/