idnits 2.17.1 draft-ietf-intarea-ippl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 30, 2017) is 2583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1Q-1998' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-10) exists of draft-ietf-dnssd-hybrid-06 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA E. Nordmark 3 Internet-Draft March 30, 2017 4 Intended status: Standards Track 5 Expires: October 1, 2017 7 IP over Intentionally Partially Partitioned Links 8 draft-ietf-intarea-ippl-00 10 Abstract 12 IP makes certain assumptions about the L2 forwarding behavior of a 13 multi-access IP link. However, there are several forms of 14 intentional partitioning of links ranging from split-horizon to 15 Private VLANs that violate some of those assumptions. This document 16 specifies that link behavior and how IP handles links with those 17 properties. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 1, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Keywords and Terminology . . . . . . . . . . . . . . . . . . 3 55 3. Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Bridge Configuration for Private VLANs . . . . . . . . . 4 57 3.2. Resulting Bridge Behavior . . . . . . . . . . . . . . . . 6 58 4. IP over IPPL . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5. IPv6 over IPPL . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. IPv4 over IPPL . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Multiple routers . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Multicast over IPPL . . . . . . . . . . . . . . . . . . . . . 10 63 9. DHCP Implications . . . . . . . . . . . . . . . . . . . . . . 12 64 10. Redirect Implications . . . . . . . . . . . . . . . . . . . . 12 65 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 68 14. Appendix: Layer 2 Learning Implications . . . . . . . . . . . 13 69 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 15.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 IPv4 and IPv6 can in general handle two forms of links; point-to- 77 point links when only have two IP nodes (self and remote), and multi- 78 access links with one or more nodes attached to the link. For the 79 multi-access links IP in general, and particular protocols like ARP 80 and IPv6 Neighbor Discovery, makes a few assumptions about transitive 81 and reflexive connectivity i.e., that all nodes attached to the link 82 can send packets to all other nodes. 84 There are cases where for various reasons and deployments one wants 85 what looks like one link from the perspective of IP and routing, yet 86 the L2 connectivity is restrictive. A key property is that an IP 87 subnet prefix is assigned to the link, and IP routing sees it as a 88 regular multi-access link with link-local unicast and multicast 89 addresses functioning as expected. But a host attached to the link 90 might not be able to send packets to all other hosts attached to the 91 link. The motivation for this is outside the scope of this document, 92 but in summary the motivation to preserve the single link view as 93 seen by IP routing is to conserve IP(v4) address space, and the 94 motivation to restrict communication on the link could be due to 95 (security) policy or to wireless connectivity approaches. 97 This intentional and partial partition appears in a few different 98 forms. For DSL [TR-101] and Cable [DOCSIS-MULPI] the pattern is to 99 have a single access router on the link, and all the hosts can send 100 and receive from the access router, but host-to-host communication is 101 blocked. A richer set of restrictions are possible for Private VLANs 102 (PVLAN) [RFC5517], which has a notion of three different ports i.e. 103 attachment points: isolated, community, and promiscuous. Note that 104 other techniques operate at L2/L3 boundary like [RFC4562] but those 105 are out of scope for this document. 107 The possible connectivity patterns for Private VLANs appears to be a 108 super-set of the DSL and Cable use of split horizon, thus this 109 document specifies the PVLAN behavior, shows the impact on IP/ARP/ND, 110 and specifies how IP/ARP/ND must operate to work with PVLAN. 112 If private VLANs, or the split horizon subset, has been configured at 113 layer 2 for the purposes of IPv4 address conservation, then that 114 layer 2 configuration will affect IPv6 even though IPv6 might not 115 have the same need for address conservation. 117 The cases covered in this document are where the link has been 118 intentionally partitioned, which is different from the cases where a 119 collection of links are joined to have a common IP subnet prefix. An 120 example of the differences is the expected behavior for packets sent 121 to link-local IP addresses. The issues for such multi-link subnets 122 are described in [RFC4903]. 124 2. Keywords and Terminology 126 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 127 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 128 document, are to be interpreted as described in [RFC2119]. 130 a The following terms from [RFC4861] are used without modifications: 132 node a device that implements IP. 133 router a node that forwards IP packets not explicitly 134 addressed to itself. 135 host any node that is not a router. 136 link a communication facility or medium over which nodes 137 can communicate at the link layer, i.e., the layer 138 immediately below IP. Examples are Ethernets (simple 139 or bridged), PPP links, X.25, Frame Relay, or ATM 140 networks as well as Internet-layer (or higher-layer) 141 "tunnels", such as tunnels over IPv4 or IPv6 itself. 142 interface a node's attachment to a link. 143 neighbors nodes attached to the same link. 145 This document defines the following set of terms: 147 bridge a layer-2 device which implements 802.1Q 148 port a bridge's attachment to another bridge or to a node. 150 3. Private VLAN 152 A private VLAN is a structure which uses two or more 802.1Q (VLAN) 153 values to separate what would otherwise be a single VLAN, viewed by 154 IP as a single broadcast domain, into different types of ports with 155 different L2 forwarding behavior between the different ports. A 156 private VLAN consists of a single primary VLAN and multiple secondary 157 VLANs. 159 From the perspective of both a single bridge and a collection of 160 interconnected bridges there are three different types of ports use 161 to attach nodes plus an inter-bridge port: 163 o Promiscuous: A promiscuous port can send packets to all ports that 164 are part of the private VLAN. Such packets are sent using the 165 primary VLAN ID. 166 o Isolated: Isolated VLAN ports can only send packets to promiscuous 167 ports. Such packets are sent using an isolated VLAN ID. 168 o Community: A community port is associated with a per-community 169 VLAN ID, and can send packets to both ports in the same community 170 VLAN and promiscuous ports. 171 o Inter-bridge: A port used to connect a bridge to another bridge. 173 Private VLANs is an implementation of asymmetric VLANs and Rooted- 174 Multipoint connectivity. Private VLANs were an integral part of 175 [IEEE802.1Q-1998]. The mapping between the mechanisms in that 176 standard plus the above Private VLAN notion of different types of 177 ports to the L2 forwarding behavior are somewhat complex and 178 described in the following sections. 180 3.1. Bridge Configuration for Private VLANs 182 This text is reproduced from [IEEE802.1-LIAISON] to ensure this 183 specification together with [IEEE802.1Q-1998] provide a complete 184 standard on which we can describe the IP implications. Note that 185 this section uses slightly different terminology than above e.g., 186 "root port" instead of "promiscuous port". 188 "Private VLANs" as described in this document are a combination of 189 the "Multi-Netted Server" and the "Rooted-Multipoint" use cases 190 described in 802.1Q annex F.1.3 "Asymmetric VLANs and Rooted- 191 Multipoint Connectivity". The "Multi-Netted Server" example 192 describes how a bridged network allows a server to communicate with 193 multiple mutually-isolated groups of clients by allocating a VLAN ID 194 per group. The "Rooted-Multipoint" example describes an optimization 195 that allows all groups containing a single client to share a single 196 VLAN ID while still remaining isolated from each other. 198 In the details for basic private VLANs below, all clause numbers are 199 IEEE Std 802.1Q-2014. Clause 12 is used as a reference for 200 management. The MIBs in clause 17 are constructed as an 201 implementation of the management model in clause 12, as are the YANG 202 models currently being developed. 204 o Select a set of VLAN IDs (VIDs) - let's call them the Branch VID 205 (communication from Leaf ports [hosts] to Root ports [routers]), 206 the Trunk VID (from Root ports to each other and to Leaf ports), 207 and zero or more Party VIDs (from Community ports to Root ports 208 and other Community ports in the same community). 209 o Assign all VIDs to the same FID (12.10.3.4) - this activates 210 Shared VLAN Learning and needs to be done in all bridges. 211 o For all Leaf ports: 213 * Configure the Branch VID as the PVID (the default input VID, 214 12.10.1.2.2:a). 215 * Configure the port to accept only untagged or priority tagged 216 frames (12.10.1.3.2:a:2). 217 * Configure the port to disable ingress filtering 218 (12.10.1.4.2:a:2). 219 * Create a permanent VLAN registration entry (12.7.7.1) 220 specifying a fixed registration (8.8.2:b:1:i), frames to be 221 output untagged (8.8.2:b:2) for the Trunk VID. 222 o For all Community ports: 224 * Configure the Party VID for this port's community as the PVID 225 (the default input VID, 12.10.1.2.2:a). 226 * Configure the port to accept only untagged or priority tagged 227 frames (12.10.1.3.2:a:2). 228 * Configure the port to disable ingress filtering 229 (12.10.1.4.2:a:2). 230 * Create a permanent VLAN registration entry (12.7.7.1) 231 specifying a fixed registration (8.8.2:b:1:i), frames to be 232 output untagged (8.8.2:b:2) for the Trunk VID and the Party 233 VID. 234 o For all Root ports: 236 * Configure the Trunk VID as the PVID (the default input VID, 237 12.10.1.2.2:a). 238 * Configure the port to accept only untagged or priority tagged 239 frames (12.10.1.3.2:a:2). 241 * Configure the port to disable ingress filtering 242 (12.10.1.4.2:a:2). 243 * Create a permanent VLAN registration entry (12.7.7.1) 244 specifying a fixed registration (8.8.2:b:1:i), frames to be 245 output untagged (8.8.2:b:2) for the Trunk, Branch, and all 246 Party VIDs. Alternatively, they can use the MVRP protocol 247 (11.2) to configure the VIDs dynamically. 249 The above configuration assumes the router attached to a Root port is 250 transmitting untagged frames and is participating only in this set of 251 VIDs. If the router is participating in other VLANs as well, then it 252 transmits all frames for this Private VLAN using the Trunk VID, and 253 the Root port configuration consists simply of creating the permanent 254 VLAN registration entries for all VIDs specifying a fixed 255 registration and frames to be output tagged. 257 Note that the set of Trunk, Branch, and all Party VIDs, together, 258 implement a single VLAN with special connectivity properties - not 259 separate VLANs. The connectivity of that VLAN is: 261 o Frames transmitted from Root ports can be received by all ports on 262 the VLAN. 263 o Frames transmitted from Leaf ports can only be received by Root 264 ports on the VLAN. 265 o Frames transmitted from Community ports can only be received by 266 Root ports and other Community ports (in the same community) on 267 the VLAN. 269 3.2. Resulting Bridge Behavior 271 Once a bridge or a set of interconnected bridges have been configured 272 with both the primary and isolated VLAN ID, and zero or more 273 community VLAN IDs associated with the private VLAN, it results in 274 the following L2 forwarding behaviors for the bridge: 276 o A packet received on an isolated port will not be L2 forwarded out 277 an isolated or community port; it will (subject to bandwidth/ 278 resource issues) be L2 forwarded out promiscuous and inter-bridge 279 ports. 280 o A packet received on a community port will not be L2 forwarded out 281 an isolated port or a community port with a different VLAN ID; it 282 will be L2 forwarded out promiscuous and inter-bridge ports as 283 well as community ports that have the same community VLAN ID. 284 o A packet received on a promiscuous port will be L2 forwarded out 285 all types of ports in the private VLAN. 286 o A packet received on an inter-bridge port with an isolated VLAN ID 287 will be L2 forwarded as a packet received on an isolated port. 289 o A packet received on an inter-bridge port with a community VLAN ID 290 will be L2 forwarded as a packet received on a community port 291 associated with that VLAN ID. 292 o A packet received on an inter-bridge port with a promiscuous VLAN 293 ID will be L2 forwarded as a packet received on a promiscuous 294 port. 296 In addition to the above VLAN filtering and implied MAC address 297 learning rules, the L2 packet forwarding is also subject to the 298 normal 802.1Q rules with blocking ports due to spanning-tree protocol 299 etc. 301 4. IP over IPPL 303 When IP is used over Intentionally Partially Partitioned links like 304 private VLANs the normal usage is to attached routers (and 305 potentially other shared resources like servers) to promiscuous 306 ports, while attaching other hosts to either community or isolated 307 ports. If there is a single host for a given tenant or other domain 308 of separation, then it is most efficient to attach that host to an 309 isolated port. If there are multiple hosts in the private VLAN that 310 should be able to communicate at layer 2, then they should be 311 assigned a common community VLAN ID and attached to ports with that 312 VLAN ID. 314 The above configuration means that hosts will not be able to 315 communicate with each other unless they are in the same community. 316 However, mechanisms outside of the scope of this document can be used 317 to allow IP communication between such hosts e.g., by having firewall 318 or gateway in or beyond the routers connected to the promiscuous 319 ports. When such a policy is in place it is important that all 320 packets which cross communities are sent to a router, which can have 321 access-control lists or deeper firewall rules to decide which packets 322 to IP forward. 324 5. IPv6 over IPPL 326 IPv6 Neighbor Discovery [RFC4861] can be used to get all the hosts on 327 the link to send all unicast packets except those send to link-local 328 destination addresses to the routers. That is done by setting the 329 L-flag (on-link) to zero for all of the Prefix Information options. 330 Note that this is orthogonal to whether SLAAC (Stateless Address 331 Auto-Configuration) [RFC4862] or DHCPv6 [RFC3315] is used for address 332 auto-configuration. Setting the L-flag to zero is RECOMMENDED 333 configuration for private VLANs. 335 If the policy includes allowing some packets that are sent to link- 336 local destinations to cross between different tenants, then some for 337 of NS/NA proxy is needed in the routers, and the routers need to IP 338 forward packets addressed to link-local destinations out the same 339 interface as REQUIRED in [RFC2460]. If the policy allows for some 340 packets sent to global IPv6 address to cross between tenants then the 341 routers would IP forward such packets out the same interface. 342 However, with the L=0 setting those global packets will be sent to 343 the default router, while the link-local destinations would result in 344 a Neighbor Solicitation to resolve the IPv6 to link-layer address 345 binding. Handling such a NS when there are multiple promiscuous 346 ports hence multiple routers risks creating loops. If the router 347 already has a neighbor cache entry for the destination it can respond 348 with an NA on behalf of the destination. However, if it does not it 349 MUST NOT send a NS on the link, since the NA will be received by the 350 other router(s) on the link which can cause an unbounded flood of 351 multicast NS packets (all with hoplimit 255), in particular of the 352 host IPv6 address does not respond. Note that such an NS/NA proxy is 353 defined in [RFC4389] under some topological assumptions such as there 354 being a distinct upstream and downstream direction, which is not the 355 case of two or more peer routers on the same IPPL. For that reason 356 NS/NA packet proxies as in [RFC4389] MUST NOT be used with IPPL. 358 IPv6 includes Duplicate Address Detection [RFC4862], which assumes 359 that a link-local IPv6 multicast can be received by all hosts which 360 are attached to the same link. That is not the case in a private 361 VLAN, hence there could potentially be undetected duplicate IPv6 362 addresses. However, the DAD proxy approach [RFC6957] defined for 363 split-horizon behavior can safely be used even when there are 364 multiple promiscuous ports hence multiple routers attached to the 365 link, since it does not rely on sending Neighbor Solicitations 366 instead merely gathers state from received packets. The use of 367 [RFC6957] with private VLAN is RECOMMENDED. 369 The Router Advertisements in a private VLAN MUST be sent out on a 370 promiscuous VLAN ID so that all nodes on the link receive them. 372 6. IPv4 over IPPL 374 IPv4 [RFC0791] and ARP [RFC0826] do not have a counterpart to the 375 Neighbor Discovery On-link flag. Hence nodes attached to isolated or 376 community ports will always ARP for any destination which is part of 377 its configured subnet prefix, and those ARP request packets will not 378 be L2 forwarded by the bridges to the target nodes. Thus the routers 379 attached to the promiscuous ports MUST provide a robust proxy ARP 380 mechanism if they are to allow any (firewalled) communication between 381 nodes from different tenants or separation domains. 383 For the ARP proxy to be robust it MUST avoid loops where router1 384 attached to the link sends an ARP request which is received by 385 router2 (also attached to the link), resulting in an ARP request from 386 router2 to be received by router1. Likewise, it MUST avoids a 387 similar loop involving IP packets, where the reception of an IP 388 packet results in sending a ARP request from router1 which is proxied 389 by router2. At a minimum, the reception of an ARP request MUST NOT 390 result in sending an ARP request, and the routers MUST either be 391 configured to know each others MAC addresses, or receive the VLAN 392 tagged packets so they can avoid proxying when the packet is received 393 with the promiscuous VLAN ID. Note that should there be an IP 394 forwarding loop due to proxying back and forth, the IP TTL will 395 expire avoiding unlimited loops. 397 Any proxy ARP approach MUST work correctly with Address Conflict 398 Detection [RFC5227]. ACD depends on ARP probes only receiving 399 responses if there is a duplicate IP address, thus the ARP probes 400 MUST NOT be proxied. These ARP probes have a Sender Protocol Address 401 of zero, hence they are easy to identify. 403 When proxying an ARP request (with a non-zero Sender Protocol 404 Address) the router needs to respond by placing its own MAC address 405 in the Sender Hardware Address field. When there are multiple 406 routers attached to the private VLAN this will not only result in 407 multiple ARP replies for each ARP request, those replies would have a 408 different Sender Hardware Address. That might seem surprising to the 409 requesting node, but does not cause an issue with ARP implementations 410 that follow the pseudo-code in [RFC0826]. 412 If the two or more routers attached to the private VLAN implement 413 VRRP [RFC5798] the routers MAY use their VRRP MAC address as the 414 Sender Hardware Address in the proxied ARP replies, since this 415 reduces the risk nodes that do not follow the pseudo-code in 416 [RFC0826]. However, if they do so it can cause flapping of the MAC 417 tables in the bridges between the routers and the ARPing node. Thus 418 such use is NOT RECOMMENDED in general topologies of bridges but can 419 be used when there are no intervening bridges. 421 7. Multiple routers 423 In addition to the above issues when multiple routers are attached to 424 the same PVLAN, the routers need to avoid potential routing loops for 425 packets entering the subnet. When such a packet arrives the router 426 might need to send a ARP request (or Neighbor Solicitation) for the 427 host, which can trigger the other router to send a proxy ARP (or 428 Neighbor Advertisement). The host, if present, will also respond to 429 the ARP/NS. This issue is described in [PVLAN-HOSTING] in the 430 particular case of HSRP. 432 When multiple routers are attached to the same PVLAN, whether they 433 are using VRRP, HSRP, or neither, they SHOULD NOT proxy ARP/ND 434 respond to a request from another router. At a minimum a router MUST 435 be configurable with a list of IP addresses to which it should not 436 proxy respond. Thus the user can configure that list with the IP 437 address(es) of the other router(s) attached to the PVLAN. 439 8. Multicast over IPPL 441 Layer 2 multicast or broadcast is used by protocols like ARP 442 [RFC0826], IPv6 Neighbor Discovery [RFC4861] and Multicast DNS 443 [RFC6762] with link-local scope. The first two have been discussed 444 above. 446 Multicast DNS can be handled by implementing using some proxy such as 447 [I-D.ietf-dnssd-hybrid] but that is outside of the scope of this 448 document. 450 IP Multicast which spans across multiple IP links and that have 451 senders that are on community or isolated ports require additional IP 452 forwarding mechanisms in the routers that are attached to the 453 promiscuous ports, since the routers need to IP forward such packets 454 out to any allowed receivers in the private VLAN without resulting in 455 packet duplication. For multicast senders on isolated ports such IP 456 forwarding would result in the sender receiving the packet it 457 transmitted. For multicast senders on community ports, any receivers 458 in the same community VLAN are subject to receiving duplicate 459 packets; one copy directly from layer 2 from the sender and a second 460 copy IP forwarded by the multicast router. 462 +------+--------+ 463 | Eth2 | 464 | Router | #4 route to other subnets 465 | Eth1 | Members on Eth1 interface 466 +-------+-------+ 467 ^ | 468 | #3 to VID 10 | | #5 to promisc VID 469 | v 470 | 471 +-------+-------+ 472 | | #6 bridge in promisc VID 473 | Bridge | 474 | | #2 bridge in VID 10 475 +--+--+--+--+---+ 476 | | | | 477 +----------------+ | | +----------------+ 478 | +-----+ +-----+ | 479 | | | | | #3 to VID 10 480 | ^ #1 to | | | v 481 | | VID 10 | | | 482 | | | # 7 to | | # 7 to | | #7 to promisc VID 483 | | v promisc | v promisc | v 484 | | VID | VID | 485 | | | | 486 | | | | 487 | | | | 488 | | | | 489 +----+-----+ +-----+----+ +----+-----+ +-----+----+ 490 | Community| | Community| | Isolated | | Community| 491 | VID 10 | | VID 20 | | VID 99 | | VID 10 | 492 | Host 1 | | Host 2 | | Host 3 | | Host 4 | 493 +----------+ +-----+----+ +----------+ +----------+ 495 Figure 1: Example upstream multicast duplication 497 The example in the figure shows where the router has been configured 498 to route multicast packets out the ingress PVLAN interface so that 499 receivers on isolated ports and in other communities will receive 500 packets sent by Host 1. But that has the side effect of Host 4, 501 which is in the same community as Host 1 will receive both a bridged 502 and a routed packet. Alternatively, if the router is configured to 503 not route multicast out the ingress PVLAN interface, then Host 2 and 504 Host 3 would not receive the packet. 506 For that reason it is NOT RECOMMENDED to configure outbound multicast 507 IP forwarding from private VLANs. 509 9. DHCP Implications 511 With IPv4 both a static configuration and a DHCPv4 configuration will 512 assign a subnet prefix to any hosts including those attached to the 513 isolated or community ports. Hence the above robust proxy ARP is 514 needed even in the case of DHCPv4. 516 With IPv6 static configuration, or SLAAC (Stateless Address Auto- 517 Configuration) [RFC4862] or DHCPv6 [RFC3315] can be used to configure 518 the IPv6 addresses on the interfaces. However, when DHCPv6 is used 519 to configure the IPv6 addresses it does not configure any notion of 520 an on-link prefix length. Thus in that case the on-link 521 determination comes from the Router Advertisement. Hence the above 522 approach of setting L=0 in the Prefix Information Option will result 523 in packets being sent to the default router(s). 525 Hence no special considerations are needed for DHCPv4 or DHCPv6. 527 10. Redirect Implications 529 ICMP redirects can be used for both IPv4 and IPv6 to indicate a 530 better first-hop router to hosts, and in addition for IPv6 can be 531 used to indicate the direct link-layer address to use to send to a 532 node which is on the link. ICMP redirects to another router which 533 attached to a promiscuous port would work since the host can reach 534 it. However, communication will fail if that port is not 535 promiscuous. In addition, the IPv6 redirect to an on-link host is 536 likely to be problematic since a host is likely to be attached to an 537 isolated or community port. 539 For those reasons it is RECOMMENDED that the sending of IPv4 and IPv6 540 redirects is disabled on the routers attached to the IPPL. 542 11. Security Considerations 544 In general DAD is subject to a Denial of Service attack since a 545 malicious host can claim all the IPv6 addresses [RFC3756]. Same 546 issue applies to IPv4/ARP when Address Conflict Detection [RFC5227] 547 is implemented. 549 12. IANA Considerations 551 There are no IANA actions needed for this document. 553 13. Acknowledgements 555 The author is grateful for the comments from Mikael Abrahamsson, Fred 556 Baker, Wes Beebee, Hemant Singh, Dave Thaler, Pascal Thubert, and 557 Sowmini Varadhan, and also the IEEE 802.1 Working Group in general 558 and Norm Finn and Steve Haddock in particular for their careful 559 review and providing the text in [IEEE802.1-LIAISON]. 561 14. Appendix: Layer 2 Learning Implications 563 While not in scope for this document, there are some observations 564 relating to the interaction of IPPL (and private VLANs in particular) 565 and layer 2 learning which are worth mentioning. Depending on the 566 details of how the deployed Ethernet bridges perform learning, a side 567 effect of using a different .1Q tag for packets sent from the routers 568 than for packets sent towards the routers mean that the 802.1Q 569 learning and aging process in intermediate bridges might age out the 570 MAC address entry for the routers MAC address. If that happens 571 packets sent towards the router will be flooded at layer two. The 572 observed behavior is that an ARP request for the router's IP address 573 will result in re-learning the MAC address. Thus some operators work 574 around this issue by configuring the ARP aging time to be shorter 575 than the MAC aging time. 577 15. References 579 15.1. Normative References 581 [IEEE802.1Q-1998] 582 IEEE, "IEEE Standard for Local and Metropolitan Area 583 Networks: Virtual Bridged Local Area Networks", IEEE Std 584 802.1Q-1998, 1998, . 587 (Access Controlled link within page) 589 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 590 DOI 10.17487/RFC0791, September 1981, 591 . 593 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 594 Converting Network Protocol Addresses to 48.bit Ethernet 595 Address for Transmission on Ethernet Hardware", STD 37, 596 RFC 826, DOI 10.17487/RFC0826, November 1982, 597 . 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, 601 DOI 10.17487/RFC2119, March 1997, 602 . 604 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 605 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 606 December 1998, . 608 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 609 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 610 DOI 10.17487/RFC4861, September 2007, 611 . 613 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 614 Address Autoconfiguration", RFC 4862, 615 DOI 10.17487/RFC4862, September 2007, 616 . 618 [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, 619 "Duplicate Address Detection Proxy", RFC 6957, 620 DOI 10.17487/RFC6957, June 2013, 621 . 623 15.2. Informative References 625 [DOCSIS-MULPI] 626 "DOCSIS 3.0: MAC and Upper Layer Protocols Interface 627 Specification", August 2015, . 630 [I-D.ietf-dnssd-hybrid] 631 Cheshire, S., "Discovery Proxy for Multicast DNS-Based 632 Service Discovery", draft-ietf-dnssd-hybrid-06 (work in 633 progress), March 2017. 635 [IEEE802.1-LIAISON] 636 "Asymmetric (private) VLANs - comments on draft-nordmark- 637 intarea-ippl", March 2017, . 640 [PVLAN-HOSTING] 641 "PVLANs in a Hosting Environment", March 2010, 642 . 645 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 646 C., and M. Carney, "Dynamic Host Configuration Protocol 647 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 648 2003, . 650 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 651 Neighbor Discovery (ND) Trust Models and Threats", 652 RFC 3756, DOI 10.17487/RFC3756, May 2004, 653 . 655 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 656 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 657 2006, . 659 [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method 660 for Subscriber Separation on an Ethernet Access Network", 661 RFC 4562, DOI 10.17487/RFC4562, June 2006, 662 . 664 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 665 DOI 10.17487/RFC4903, June 2007, 666 . 668 [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, 669 DOI 10.17487/RFC5227, July 2008, 670 . 672 [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private 673 VLANs: Scalable Security in a Multi-Client Environment", 674 RFC 5517, DOI 10.17487/RFC5517, February 2010, 675 . 677 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 678 Version 3 for IPv4 and IPv6", RFC 5798, 679 DOI 10.17487/RFC5798, March 2010, 680 . 682 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 683 DOI 10.17487/RFC6762, February 2013, 684 . 686 [TR-101] "Migration to Ethernet-Based DSL Aggregation", The 687 Broadband Forum Technical Report TR-101, July 2011, 688 . 691 Author's Address 693 Erik Nordmark 694 Santa Clara, CA 695 USA 697 Email: nordmark@sonic.net