INTAREA E. Nordmark
Internet-Draft March 30, 2017
Intended status: Standards Track
Expires: October 1, 2017
IP over Intentionally Partially Partitioned Links
draft-ietf-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 October 1, 2017.
Copyright Notice
Copyright (c) 2017 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
Nordmark Expires October 1, 2017 [Page 1]
Internet-Draft IPPL March 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Keywords and Terminology . . . . . . . . . . . . . . . . . . 3
3. Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Bridge Configuration for Private VLANs . . . . . . . . . 4
3.2. Resulting Bridge Behavior . . . . . . . . . . . . . . . . 6
4. IP over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IPv6 over IPPL . . . . . . . . . . . . . . . . . . . . . . . 7
6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . 8
7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . 9
8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 10
9. DHCP Implications . . . . . . . . . . . . . . . . . . . . . . 12
10. Redirect Implications . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. Appendix: Layer 2 Learning Implications . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 with link-local unicast and multicast
addresses functioning as expected. 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 single link 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 to wireless connectivity approaches.
Nordmark Expires October 1, 2017 [Page 2]
Internet-Draft IPPL March 2017
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 Private VLANs appears to be a
super-set 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.
The cases covered in this document are where the link has been
intentionally partitioned, which is different from the cases where a
collection of links are joined to have a common IP subnet prefix. An
example of the differences is the expected behavior for packets sent
to link-local IP addresses. The issues for such multi-link subnets
are described in [RFC4903].
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].
a 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.
Nordmark Expires October 1, 2017 [Page 3]
Internet-Draft IPPL March 2017
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.
Private VLANs is an implementation of asymmetric VLANs and Rooted-
Multipoint connectivity. Private VLANs were an integral part of
[IEEE802.1Q-1998]. The mapping between the mechanisms in that
standard plus the above Private VLAN notion of different types of
ports to the L2 forwarding behavior are somewhat complex and
described in the following sections.
3.1. Bridge Configuration for Private VLANs
This text is reproduced from [IEEE802.1-LIAISON] to ensure this
specification together with [IEEE802.1Q-1998] provide a complete
standard on which we can describe the IP implications. Note that
this section uses slightly different terminology than above e.g.,
"root port" instead of "promiscuous port".
"Private VLANs" as described in this document are a combination of
the "Multi-Netted Server" and the "Rooted-Multipoint" use cases
described in 802.1Q annex F.1.3 "Asymmetric VLANs and Rooted-
Multipoint Connectivity". The "Multi-Netted Server" example
describes how a bridged network allows a server to communicate with
Nordmark Expires October 1, 2017 [Page 4]
Internet-Draft IPPL March 2017
multiple mutually-isolated groups of clients by allocating a VLAN ID
per group. The "Rooted-Multipoint" example describes an optimization
that allows all groups containing a single client to share a single
VLAN ID while still remaining isolated from each other.
In the details for basic private VLANs below, all clause numbers are
IEEE Std 802.1Q-2014. Clause 12 is used as a reference for
management. The MIBs in clause 17 are constructed as an
implementation of the management model in clause 12, as are the YANG
models currently being developed.
o Select a set of VLAN IDs (VIDs) - let's call them the Branch VID
(communication from Leaf ports [hosts] to Root ports [routers]),
the Trunk VID (from Root ports to each other and to Leaf ports),
and zero or more Party VIDs (from Community ports to Root ports
and other Community ports in the same community).
o Assign all VIDs to the same FID (12.10.3.4) - this activates
Shared VLAN Learning and needs to be done in all bridges.
o For all Leaf ports:
* Configure the Branch VID as the PVID (the default input VID,
12.10.1.2.2:a).
* Configure the port to accept only untagged or priority tagged
frames (12.10.1.3.2:a:2).
* Configure the port to disable ingress filtering
(12.10.1.4.2:a:2).
* Create a permanent VLAN registration entry (12.7.7.1)
specifying a fixed registration (8.8.2:b:1:i), frames to be
output untagged (8.8.2:b:2) for the Trunk VID.
o For all Community ports:
* Configure the Party VID for this port's community as the PVID
(the default input VID, 12.10.1.2.2:a).
* Configure the port to accept only untagged or priority tagged
frames (12.10.1.3.2:a:2).
* Configure the port to disable ingress filtering
(12.10.1.4.2:a:2).
* Create a permanent VLAN registration entry (12.7.7.1)
specifying a fixed registration (8.8.2:b:1:i), frames to be
output untagged (8.8.2:b:2) for the Trunk VID and the Party
VID.
o For all Root ports:
* Configure the Trunk VID as the PVID (the default input VID,
12.10.1.2.2:a).
* Configure the port to accept only untagged or priority tagged
frames (12.10.1.3.2:a:2).
Nordmark Expires October 1, 2017 [Page 5]
Internet-Draft IPPL March 2017
* Configure the port to disable ingress filtering
(12.10.1.4.2:a:2).
* Create a permanent VLAN registration entry (12.7.7.1)
specifying a fixed registration (8.8.2:b:1:i), frames to be
output untagged (8.8.2:b:2) for the Trunk, Branch, and all
Party VIDs. Alternatively, they can use the MVRP protocol
(11.2) to configure the VIDs dynamically.
The above configuration assumes the router attached to a Root port is
transmitting untagged frames and is participating only in this set of
VIDs. If the router is participating in other VLANs as well, then it
transmits all frames for this Private VLAN using the Trunk VID, and
the Root port configuration consists simply of creating the permanent
VLAN registration entries for all VIDs specifying a fixed
registration and frames to be output tagged.
Note that the set of Trunk, Branch, and all Party VIDs, together,
implement a single VLAN with special connectivity properties - not
separate VLANs. The connectivity of that VLAN is:
o Frames transmitted from Root ports can be received by all ports on
the VLAN.
o Frames transmitted from Leaf ports can only be received by Root
ports on the VLAN.
o Frames transmitted from Community ports can only be received by
Root ports and other Community ports (in the same community) on
the VLAN.
3.2. Resulting 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, it results in
the following L2 forwarding behaviors for the bridge:
o A packet received on an isolated port will not be L2 forwarded out
an isolated or community port; it will (subject to bandwidth/
resource issues) be L2 forwarded out promiscuous and inter-bridge
ports.
o A packet received on a community port will not be L2 forwarded out
an isolated port or a community port with a different VLAN ID; it
will be L2 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 will be L2 forwarded out
all types of ports in the private VLAN.
o A packet received on an inter-bridge port with an isolated VLAN ID
will be L2 forwarded as a packet received on an isolated port.
Nordmark Expires October 1, 2017 [Page 6]
Internet-Draft IPPL March 2017
o A packet received on an inter-bridge port with a community VLAN ID
will be L2 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 will be L2 forwarded as a packet received on a promiscuous
port.
In addition to the above VLAN filtering and implied MAC address
learning rules, the L2 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 IP forward.
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
auto-configuration. 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
Nordmark Expires October 1, 2017 [Page 7]
Internet-Draft IPPL March 2017
of NS/NA proxy is needed in the routers, and the routers need to IP
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 IP 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
are attached to the same link. 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.
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 L2 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
Nordmark Expires October 1, 2017 [Page 8]
Internet-Draft IPPL March 2017
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
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. 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.
Nordmark Expires October 1, 2017 [Page 9]
Internet-Draft IPPL March 2017
When multiple routers are attached to the same PVLAN, whether 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 IP
forwarding mechanisms in the routers that are attached to the
promiscuous ports, since the routers need to IP forward such packets
out to any allowed receivers in the private VLAN without resulting in
packet duplication. For multicast senders on isolated ports such IP
forwarding would result in the sender 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 IP forwarded by the multicast router.
Nordmark Expires October 1, 2017 [Page 10]
Internet-Draft IPPL March 2017
+------+--------+
| Eth2 |
| Router | #4 route to other subnets
| Eth1 | Members on Eth1 interface
+-------+-------+
^ |
| #3 to VID 10 | | #5 to promisc VID
| v
|
+-------+-------+
| | #6 bridge in promisc VID
| Bridge |
| | #2 bridge in VID 10
+--+--+--+--+---+
| | | |
+----------------+ | | +----------------+
| +-----+ +-----+ |
| | | | | #3 to VID 10
| ^ #1 to | | | v
| | VID 10 | | |
| | | # 7 to | | # 7 to | | #7 to promisc VID
| | v promisc | v promisc | v
| | VID | VID |
| | | |
| | | |
| | | |
| | | |
+----+-----+ +-----+----+ +----+-----+ +-----+----+
| Community| | Community| | Isolated | | Community|
| VID 10 | | VID 20 | | VID 99 | | VID 10 |
| Host 1 | | Host 2 | | Host 3 | | Host 4 |
+----------+ +-----+----+ +----------+ +----------+
Figure 1: Example upstream multicast duplication
The example in the figure shows where the router has been configured
to route multicast packets out the ingress PVLAN interface so that
receivers on isolated ports and in other communities will receive
packets sent by Host 1. But that has the side effect of Host 4,
which is in the same community as Host 1 will receive both a bridged
and a routed packet. Alternatively, if the router is configured to
not route multicast out the ingress PVLAN interface, then Host 2 and
Host 3 would not receive the packet.
For that reason it is NOT RECOMMENDED to configure outbound multicast
IP forwarding from private VLANs.
Nordmark Expires October 1, 2017 [Page 11]
Internet-Draft IPPL March 2017
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 promiscuous port would work since the host can reach
it. However, communication will fail if that port is not
promiscuous. 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
malicious host can claim all the IPv6 addresses [RFC3756]. Same
issue applies to IPv4/ARP when Address Conflict Detection [RFC5227]
is implemented.
12. IANA Considerations
There are no IANA actions needed for this document.
Nordmark Expires October 1, 2017 [Page 12]
Internet-Draft IPPL March 2017
13. Acknowledgements
The author is grateful for the comments from Mikael Abrahamsson, Fred
Baker, Wes Beebee, Hemant Singh, Dave Thaler, Pascal Thubert, and
Sowmini Varadhan, and also the IEEE 802.1 Working Group in general
and Norm Finn and Steve Haddock in particular for their careful
review and providing the text in [IEEE802.1-LIAISON].
14. Appendix: Layer 2 Learning Implications
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
[IEEE802.1Q-1998]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Virtual Bridged Local Area Networks", IEEE Std
802.1Q-1998, 1998, <https://standards.ieee.org/findstds/
standard/802.1Q-1998.html>.
(Access Controlled link within page)
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[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,
<http://www.rfc-editor.org/info/rfc826>.
Nordmark Expires October 1, 2017 [Page 13]
Internet-Draft IPPL March 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[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,
<http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li,
"Duplicate Address Detection Proxy", RFC 6957,
DOI 10.17487/RFC6957, June 2013,
<http://www.rfc-editor.org/info/rfc6957>.
15.2. Informative References
[DOCSIS-MULPI]
"DOCSIS 3.0: MAC and Upper Layer Protocols Interface
Specification", August 2015, <http://www.cablelabs.com/wp-
content/uploads/specdocs/CM-SP-MULPIv3.0-I28-150827.pdf>.
[I-D.ietf-dnssd-hybrid]
Cheshire, S., "Discovery Proxy for Multicast DNS-Based
Service Discovery", draft-ietf-dnssd-hybrid-06 (work in
progress), March 2017.
[IEEE802.1-LIAISON]
"Asymmetric (private) VLANs - comments on draft-nordmark-
intarea-ippl", March 2017, <https://datatracker.ietf.org/
liaison/1510/>.
[PVLAN-HOSTING]
"PVLANs in a Hosting Environment", March 2010,
<https://puck.nether.net/pipermail/cisco-
nsp/2010-March/068469.html>.
Nordmark Expires October 1, 2017 [Page 14]
Internet-Draft IPPL March 2017
[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, <http://www.rfc-editor.org/info/rfc3315>.
[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,
<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
for Subscriber Separation on an Ethernet Access Network",
RFC 4562, DOI 10.17487/RFC4562, June 2006,
<http://www.rfc-editor.org/info/rfc4562>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<http://www.rfc-editor.org/info/rfc4903>.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227,
DOI 10.17487/RFC5227, July 2008,
<http://www.rfc-editor.org/info/rfc5227>.
[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,
<http://www.rfc-editor.org/info/rfc5517>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798,
DOI 10.17487/RFC5798, March 2010,
<http://www.rfc-editor.org/info/rfc5798>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[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 October 1, 2017 [Page 15]
Internet-Draft IPPL March 2017
Author's Address
Erik Nordmark
Santa Clara, CA
USA
Email: nordmark@sonic.net
Nordmark Expires October 1, 2017 [Page 16]
