Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-nordmark-intarea-ippl-03.txt Дата изменения: Mon Mar 21 21:12:18 2016 Дата индексирования: Sun Apr 10 07:07:59 2016 Кодировка: Поисковые слова: horizon

INTAREA E. Nordmark
Internet-Draft Arista Networks
Intended status: Standards Track Mar 2016
Expires: September 2, 2016


IP over Intentionally Partially Partitioned Links
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.

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 September 2, 2016.

Copyright Notice

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



Nordmark Expires September 2, 2016 [Page 1]

Internet-Draft IPPL Mar 2016


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 . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . . 8
8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 8
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






























Nordmark Expires September 2, 2016 [Page 2]

Internet-Draft IPPL Mar 2016


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 [DOCSIS-MULPI] 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 September 2, 2016 [Page 3]

Internet-Draft IPPL Mar 2016


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 September 2, 2016 [Page 4]

Internet-Draft IPPL Mar 2016


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. When such a policy is in place it is important that all
packets which cross communities are sent to a router, which can have
access-control lists or deeper firewall rules to decide which packets
to forward.






Nordmark Expires September 2, 2016 [Page 5]

Internet-Draft IPPL Mar 2016


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




Nordmark Expires September 2, 2016 [Page 6]

Internet-Draft IPPL Mar 2016


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



Nordmark Expires September 2, 2016 [Page 7]

Internet-Draft IPPL Mar 2016


7. Multiple routers

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

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
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 outbound multicast
forwarding from private VLANs.







Nordmark Expires September 2, 2016 [Page 8]

Internet-Draft IPPL Mar 2016


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


10. IANA Considerations

There are no IANA actions needed for this document.


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

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

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

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

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless



Nordmark Expires September 2, 2016 [Page 9]

Internet-Draft IPPL Mar 2016


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

12.2. Informative References

[DOCSIS-MULPI]
"DOCSIS 3.0: MAC and Upper Layer Protocols Interface
Specification", August 2015, wp-content/uploads/specdocs/
CM-SP-MULPIv3.0-I28-150827.pdf>.

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

[PVLAN-HOSTING]
"PVLANs in a Hosting Environment", March 2010, puck.nether.net/pipermail/cisco-nsp/2010-March/
068469.html>.

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



Nordmark Expires September 2, 2016 [Page 10]

Internet-Draft IPPL Mar 2016


.

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

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

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

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


Author's Address

Erik Nordmark
Arista Networks
Santa Clara, CA
USA

Email: nordmark@arista.com





















Nordmark Expires September 2, 2016 [Page 11]