draft-nordmark-intarea-ippl-02.txt   draft-nordmark-intarea-ippl-03.txt 
INTAREA E. Nordmark INTAREA E. Nordmark
Internet-Draft Arista Networks Internet-Draft Arista Networks
Intended status: Standards Track Oct 2015 Intended status: Standards Track Mar 2016
Expires: April 3, 2016 Expires: September 2, 2016
IP over Intentionally Partially Partitioned Links IP over Intentionally Partially Partitioned Links
draft-nordmark-intarea-ippl-02 draft-nordmark-intarea-ippl-03
Abstract Abstract
IP makes certain assumptions about the L2 forwarding behavior of a IP makes certain assumptions about the L2 forwarding behavior of a
multi-access IP link. However, there are several forms of multi-access IP link. However, there are several forms of
intentional partitioning of links ranging from split-horizon to intentional partitioning of links ranging from split-horizon to
Private VLANs that violate some of those assumptions. This document Private VLANs that violate some of those assumptions. This document
specifies that link behavior and how IP handles links with those specifies that link behavior and how IP handles links with those
properties. properties.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Keywords and Terminology . . . . . . . . . . . . . . . . . . . 3 2. Keywords and Terminology . . . . . . . . . . . . . . . . . . . 3
3. Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Bridge Behavior . . . . . . . . . . . . . . . . . . . . . 4 3.1. Bridge Behavior . . . . . . . . . . . . . . . . . . . . . 4
4. IP over IPPL . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IP over IPPL . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IPv6 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IPv6 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . . 7 7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . . 8
8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 8 8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
IPv4 and IPv6 can in general handle two forms of links; point-to- 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- 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 access links with one or more nodes attached to the link. For the
multi-access links IP in general, and particular protocols like ARP multi-access links IP in general, and particular protocols like ARP
and IPv6 Neighbor Discovery, makes a few assumptions about transitive and IPv6 Neighbor Discovery, makes a few assumptions about transitive
and reflexive connectivity i.e., that all nodes attached to the link and reflexive connectivity i.e., that all nodes attached to the link
can send packets to all other nodes. can send packets to all other nodes.
skipping to change at page 6, line 20 skipping to change at page 6, line 20
L-flag (on-link) to zero for all of the Prefix Information options. L-flag (on-link) to zero for all of the Prefix Information options.
Note that this is orthogonal to whether SLAAC (Stateless Address Note that this is orthogonal to whether SLAAC (Stateless Address
Auto-Configuration) [RFC4862] or DHCPv6 [RFC3315] is used for address Auto-Configuration) [RFC4862] or DHCPv6 [RFC3315] is used for address
autoconfiguration. Setting the L-flag to zero is RECOMMENDED autoconfiguration. Setting the L-flag to zero is RECOMMENDED
configuration for private VLANs. configuration for private VLANs.
If the policy includes allowing some packets that are sent to link- If the policy includes allowing some packets that are sent to link-
local destinations to cross between different tenants, then some for local destinations to cross between different tenants, then some for
of NS/NA proxy is needed in the routers, and the routers need to of NS/NA proxy is needed in the routers, and the routers need to
forward packets addressed to link-local destinations out the same forward packets addressed to link-local destinations out the same
interface as REQUIRED in [RFC2460]. However, the necessary NS/NA interface as REQUIRED in [RFC2460]. If the policy allows for some
proxy would be non-trivial since there can be multiple promiscuous packets sent to global IPv6 address to cross between tenants then the
ports hence multiple routers thus a risk of a NS being proxied in a routers would forward such packets out the same interface. However,
loop going back out on the same link. Hence a NS/NA proxy MUST NOT with the L=0 setting those global packets will be sent to the default
be used with private VLANs. 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 IPv6 includes Duplicate Address Detection [RFC4862], which assumes
that a link-local IPv6 multicast can be received by all hosts which 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 share the same subnet prefix. That is not the case in a private
VLAN, hence there could potentially be undetected duplicate IPv6 VLAN, hence there could potentially be undetected duplicate IPv6
addresses. However, the DAD proxy approach [RFC6957] defined for addresses. However, the DAD proxy approach [RFC6957] defined for
split-horizon behavior can safely be used even when there are split-horizon behavior can safely be used even when there are
multiple promiscuous ports hence multiple routers attached to the 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 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. promiscuous VLAN ID so that all nodes on the link receive them.
6. IPv4 over IPPL 6. IPv4 over IPPL
IPv4 [RFC0791] and ARP [RFC0826] do not have a counterpart to the IPv4 [RFC0791] and ARP [RFC0826] do not have a counterpart to the
Neighbor Discovery On-link flag. Hence nodes attached to isolated or Neighbor Discovery On-link flag. Hence nodes attached to isolated or
community ports will always ARP for any destination which is part of community ports will always ARP for any destination which is part of
its configured subnet prefix, and those ARP request packets will not its configured subnet prefix, and those ARP request packets will not
skipping to change at page 8, line 4 skipping to change at page 8, line 17
In addition to the above issues when multiple routers are attached to In addition to the above issues when multiple routers are attached to
the same PVLAN, the routers need to avoid potential routing loops for the same PVLAN, the routers need to avoid potential routing loops for
packets entering the subnet. When such a packet arrives the router packets entering the subnet. When such a packet arrives the router
might need to send a ARP request (or Neighbor Solicitation) for the 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 host, which can trigger the other router to send a proxy ARP (or
Neighbor Advertisement). The host, if present, will also respond to Neighbor Advertisement). The host, if present, will also respond to
the ARP/NS. This issue is described in [PVLAN-HOSTING] in the the ARP/NS. This issue is described in [PVLAN-HOSTING] in the
particular case of HSRP. particular case of HSRP.
When multiple routers are attached to the same PVLAN, wheter they are 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 using VRRP, HSRP, or neither, they SHOULD NOT proxy ARP/ND respond to
request from another router. At a minimum a router MUST be 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 configurable with a list of IP addresses to which it should not proxy
respond. Thus the user can configure that list with the IP respond. Thus the user can configure that list with the IP
address(es) of the other router(s) attached to the PVLAN. address(es) of the other router(s) attached to the PVLAN.
8. Multicast over IPPL 8. Multicast over IPPL
Layer 2 multicast or broadcast is used by protocols like ARP Layer 2 multicast or broadcast is used by protocols like ARP
[RFC0826], IPv6 Neighbor Discovery [RFC4861] and Multicast DNS [RFC0826], IPv6 Neighbor Discovery [RFC4861] and Multicast DNS
[RFC6762] with link-local scope. The first two have been discussed [RFC6762] with link-local scope. The first two have been discussed
above. above.
skipping to change at page 8, line 47 skipping to change at page 9, line 16
In general DAD is subject to a Denial of Service attack since a In general DAD is subject to a Denial of Service attack since a
malicious host can claim all the IPv6 addresses [RFC3756]. Same malicious host can claim all the IPv6 addresses [RFC3756]. Same
issue applies to IPv4/ARP when Address Conflict Detection [RFC5227] issue applies to IPv4/ARP when Address Conflict Detection [RFC5227]
is implemented. is implemented.
10. IANA Considerations 10. IANA Considerations
There are no IANA actions needed for this document. There are no IANA actions needed for this document.
11. References 11. Acknowledgements
11.1. Normative References
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, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37, Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982, RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>. <http://www.rfc-editor.org/info/rfc826>.
skipping to change at page 9, line 40 skipping to change at page 10, line 13
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, DOI 10.17487/ Address Autoconfiguration", RFC 4862, DOI 10.17487/
RFC4862, September 2007, RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li,
"Duplicate Address Detection Proxy", RFC 6957, "Duplicate Address Detection Proxy", RFC 6957,
DOI 10.17487/RFC6957, June 2013, DOI 10.17487/RFC6957, June 2013,
<http://www.rfc-editor.org/info/rfc6957>. <http://www.rfc-editor.org/info/rfc6957>.
11.2. Informative References 12.2. Informative References
[DOCSIS-MULPI] [DOCSIS-MULPI]
"DOCSIS 3.0: MAC and Upper Layer Protocols Interface "DOCSIS 3.0: MAC and Upper Layer Protocols Interface
Specification", August 2015, <http://www.cablelabs.com/ Specification", August 2015, <http://www.cablelabs.com/
wp-content/uploads/specdocs/ wp-content/uploads/specdocs/
CM-SP-MULPIv3.0-I28-150827.pdf>. CM-SP-MULPIv3.0-I28-150827.pdf>.
[I-D.ietf-dnssd-hybrid] [I-D.ietf-dnssd-hybrid]
Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
Discovery", draft-ietf-dnssd-hybrid-00 (work in progress), Discovery", draft-ietf-dnssd-hybrid-03 (work in progress),
November 2014. February 2016.
[PVLAN-HOSTING] [PVLAN-HOSTING]
"PVLANs in a Hosting Environment", March 2010, <https:// "PVLANs in a Hosting Environment", March 2010, <https://
puck.nether.net/pipermail/cisco-nsp/2010-March/ puck.nether.net/pipermail/cisco-nsp/2010-March/
068469.html>. 068469.html>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
July 2003, <http://www.rfc-editor.org/info/rfc3315>. July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004, RFC 3756, DOI 10.17487/RFC3756, May 2004,
<http://www.rfc-editor.org/info/rfc3756>. <http://www.rfc-editor.org/info/rfc3756>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389,
April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method
for Subscriber Separation on an Ethernet Access Network", for Subscriber Separation on an Ethernet Access Network",
RFC 4562, DOI 10.17487/RFC4562, June 2006, RFC 4562, DOI 10.17487/RFC4562, June 2006,
<http://www.rfc-editor.org/info/rfc4562>. <http://www.rfc-editor.org/info/rfc4562>.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
DOI 10.17487/RFC5227, July 2008, DOI 10.17487/RFC5227, July 2008,
<http://www.rfc-editor.org/info/rfc5227>. <http://www.rfc-editor.org/info/rfc5227>.
[RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private
 End of changes. 13 change blocks. 
26 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/