draft-nordmark-intarea-ippl-04.txt   draft-nordmark-intarea-ippl-05.txt 
INTAREA E. Nordmark INTAREA E. Nordmark
Internet-Draft Arista Networks Internet-Draft Arista Networks
Intended status: Standards Track Jul 2016 Intended status: Standards Track October 26, 2016
Expires: January 2, 2017 Expires: April 29, 2017
IP over Intentionally Partially Partitioned Links IP over Intentionally Partially Partitioned Links
draft-nordmark-intarea-ippl-04 draft-nordmark-intarea-ippl-05
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.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 2, 2017. This Internet-Draft will expire on April 29, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . . . . . 5
6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . 6
7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . . 8 7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . 7
8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 8 8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. DHCP Implications . . . . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Redirect Implications . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 10 14. Appendix: Layer 2 Implications . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
15.1. Normative References . . . . . . . . . . . . . . . . . . 10
15.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 9, line 5 skipping to change at page 8, line 31
packet duplication. For multicast senders on isolated ports such packet duplication. For multicast senders on isolated ports such
forwarding would result in the sender potentially receiving the forwarding would result in the sender potentially receiving the
packet it transmitted. For multicast senders on community ports, any packet it transmitted. For multicast senders on community ports, any
receivers in the same community VLAN are subject to receiving receivers in the same community VLAN are subject to receiving
duplicate packets; one copy directly from layer 2 from the sender and duplicate packets; one copy directly from layer 2 from the sender and
a second copy forwarded by the multicast router. a second copy forwarded by the multicast router.
For that reason it is NOT RECOMMENDED to configure outbound multicast For that reason it is NOT RECOMMENDED to configure outbound multicast
forwarding from private VLANs. forwarding from private VLANs.
9. Security Considerations 9. DHCP Implications
With IPv4 both a static configuration and a DHCPv4 configuration will
assign a subnet prefix to any hosts including those attached to the
isolated or community ports. Hence the above robust proxy ARP is
needed even in the case of DHCPv4.
With IPv6 static configuration, or SLAAC (Stateless Address Auto-
Configuration) [RFC4862] or DHCPv6 [RFC3315] can be used to configure
the IPv6 addresses on the interfaces. However, when DHCPv6 is used
to configure the IPv6 addresses it does not configure any notion of
an on-link prefix length. Thus in that case the on-link
determination comes from the Router Advertisement. Hence the above
approach of setting L=0 in the Prefix Information Option will result
in packets being sent to the default router(s).
Hence no special considerations are needed for DHCPv4 or DHCPv6.
10. Redirect Implications
ICMP redirects can be used for both IPv4 and IPv6 to indicate a
better first-hop router to hosts, and in addition for IPv6 can be
used to indicate the direct link-layer address to use to send to a
node which is on the link. ICMP redirects to another router which
attached to a promiscious port would work since the host can reach
it. However, communication will fail if that port is not promicious.
In addition, the IPv6 redirect to an on-link host is likely to be
problematic since a host is likely to be attached to an isolated or
community port.
For those reasons it is RECOMMENDED that the sending of IPv4 and IPv6
redirects is disabled on the routers attached to the IPPL.
11. Security Considerations
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 12. IANA Considerations
There are no IANA actions needed for this document. There are no IANA actions needed for this document.
11. Acknowledgements 13. Acknowledgements
The author is grateful for the comments from Mikael Abrahamsson, Fred The author is grateful for the comments from Mikael Abrahamsson, Fred
Baker, Wes Beebee, Hemant Singh, Dave Thaler, and Sowmini Varadhan. Baker, Wes Beebee, Hemant Singh, Dave Thaler, and Sowmini Varadhan.
12. References 14. Appendix: Layer 2 Implications
12.1. Normative References While not in scope for this document, there are some observations
relating to the interaction of IPPL (and private VLANs in particular)
and layer 2 learning which are worth mentioning. Depending on the
details of how the deployed Ethernet bridges perform learning, a side
effect of using a different .1Q tag for packets sent from the routers
than for packets sent towards the routers mean that the 802.1Q
learning and aging process in intermediate bridges might age out the
MAC address entry for the routers MAC address. If that happens
packets sent towards the router will be flooded at layer two. The
observed behavior is that an ARP request for the router's IP address
will result in re-learning the MAC address. Thus some operators work
around this issue by configuring the ARP aging time to be shorter
than the MAC aging time.
15. References
15.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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[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,
RFC4862, September 2007, DOI 10.17487/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>.
12.2. Informative References 15.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-
wp-content/uploads/specdocs/ 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-03 (work in progress), Discovery", draft-ietf-dnssd-hybrid-03 (work in progress),
February 2016. February 2016.
[PVLAN-HOSTING] [PVLAN-HOSTING]
"PVLANs in a Hosting Environment", March 2010, <https:// "PVLANs in a Hosting Environment", March 2010,
puck.nether.net/pipermail/cisco-nsp/2010-March/ <https://puck.nether.net/pipermail/cisco-
068469.html>. nsp/2010-March/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
July 2003, <http://www.rfc-editor.org/info/rfc3315>. 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 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
April 2006, <http://www.rfc-editor.org/info/rfc4389>. 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
VLANs: Scalable Security in a Multi-Client Environment", VLANs: Scalable Security in a Multi-Client Environment",
RFC 5517, DOI 10.17487/RFC5517, February 2010, RFC 5517, DOI 10.17487/RFC5517, February 2010,
<http://www.rfc-editor.org/info/rfc5517>. <http://www.rfc-editor.org/info/rfc5517>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/ Version 3 for IPv4 and IPv6", RFC 5798,
RFC5798, March 2010, DOI 10.17487/RFC5798, March 2010,
<http://www.rfc-editor.org/info/rfc5798>. <http://www.rfc-editor.org/info/rfc5798>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[TR-101] "Migration to Ethernet-Based DSL Aggregation", The [TR-101] "Migration to Ethernet-Based DSL Aggregation", The
Broadband Forum Technical Report TR-101, July 2011, <http: Broadband Forum Technical Report TR-101, July 2011,
//www.broadband-forum.org/technical/download/ <http://www.broadband-forum.org/technical/download/
TR-101_Issue-2.pdf>. TR-101_Issue-2.pdf>.
Author's Address Author's Address
Erik Nordmark Erik Nordmark
Arista Networks Arista Networks
Santa Clara, CA Santa Clara, CA
USA USA
Email: nordmark@arista.com Email: nordmark@arista.com
 End of changes. 19 change blocks. 
45 lines changed or deleted 96 lines changed or added

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