idnits 2.17.1
draft-grundemann-homenet-hipnet-01.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 :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
== There are 1 instance of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 129 has weird spacing: '... Router a nod...'
-- The document date (February 25, 2013) is 4077 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'UPNnP-IGD' is mentioned on line 195, but not defined
== Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line
870, but no explicit reference was found in the text
** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415)
** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415)
== Outdated reference: A later version (-05) exists of
draft-donley-dhc-cer-id-option-01
== Outdated reference: A later version (-17) exists of
draft-ietf-homenet-arch-07
Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group C. Grundemann
3 Internet-Draft C. Donley
4 Intended status: Informational CableLabs
5 Expires: August 29, 2013 J. Brzozowski
6 Comcast Cable Communications
7 L. Howard
8 Time Warner Cable
9 V. Kuarsingh
10 Rogers Communications
11 February 25, 2013
13 A Near Term Solution for Home IP Networking (HIPnet)
14 draft-grundemann-homenet-hipnet-01
16 Abstract
18 Home networks are becoming more complex. With the launch of new
19 services such as home security, IP video, Smart Grid, etc., many
20 Service Providers are placing additional IPv4/IPv6 routers on the
21 subscriber network. This document describes a self-configuring home
22 router that is capable of operating in such an environment, and that
23 requires no user interaction to configure it. Compliant with
24 draft-ietf-homenet-arch, it uses existing protocols in new ways
25 without the need for a routing protocol.
27 Requirements Language
29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
31 document are to be interpreted as described in RFC 2119 [RFC2119].
33 Status of this Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on August 29, 2013.
50 Copyright Notice
52 Copyright (c) 2013 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
70 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
71 3.1. Current End-User Network Architecture . . . . . . . . . . 5
72 3.2. HIPNet End-User Network Architecture . . . . . . . . . . . 6
73 4. Network Detection . . . . . . . . . . . . . . . . . . . . . . 8
74 4.1. Edge Detection . . . . . . . . . . . . . . . . . . . . . . 8
75 4.2. Directionless Home Routers . . . . . . . . . . . . . . . . 9
76 5. Routing and Addressing . . . . . . . . . . . . . . . . . . . . 10
77 5.1. Recursive Prefix Delegation . . . . . . . . . . . . . . . 11
78 5.2. Prefix Sub-Delegation Requirements . . . . . . . . . . . . 12
79 5.3. Multiple Address Family Support . . . . . . . . . . . . . 13
80 5.4. Hierarchical Routing . . . . . . . . . . . . . . . . . . . 13
81 6. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . . . 13
82 6.1. Backup Connection . . . . . . . . . . . . . . . . . . . . 14
83 6.2. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . 14
84 6.2.1. Multihoming Requirements . . . . . . . . . . . . . . . 16
85 7. Mulicast Support . . . . . . . . . . . . . . . . . . . . . . . 17
86 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 17
87 7.2. Multicast Proxy Support . . . . . . . . . . . . . . . . . 17
88 7.3. Multicast Requirements . . . . . . . . . . . . . . . . . . 17
89 8. Firewall Support . . . . . . . . . . . . . . . . . . . . . . . 18
90 8.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
95 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
96 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
100 1. Introduction
102 This document expands upon [I-D.ietf-v6ops-6204bis] to describe IPv6/
103 IPv4 features for a residential or small-office router, referred to
104 as a HIPnet router. Consistent with [I-D.ietf-homenet-arch], it
105 focuses on network technology evolution to support increasingly large
106 residential/SoHo networks. While the primary focus is on IPv6
107 support, this document also describes how to leverage IPv6 to
108 configure IPv4 in a manner better than nested NATs in operation on
109 many networks today.
111 This document specifies how a HIPnet router automatically detects
112 both the edge of the customer network and its upstream interface, how
113 it subdivides an IPv6 prefix to distribute to downstream routers, and
114 how it leverages IPv6 address assignment to distribute IPv4
115 addresses. It also discusses how such a router can operate with a
116 backup ISP or limited multihoming across two ISPs.
118 1.1. Requirements Language
120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
122 document are to be interpreted as described in RFC 2119 [RFC2119].
124 2. Terminology
126 End-User Network one or more links attached to the HIPnet
127 router that connect IPv6 and IPv4 hosts.
129 Home IP Network (HIPnet) Router a node intended for home or small-
130 office use that forwards packets not
131 explicitly addressed to itself.
133 Customer Edge Router (CER) a HIPnet router that connects the end-
134 user network to a service provider network.
136 Internal Router an additional HIPnet router deployed in the
137 home or small-office network that is not
138 attached to a service provider network.
139 Note that this is a functional role; it is
140 expected that there will not be a
141 difference in hardware or software between
142 a CER and IR, except in such cases when a
143 CER has a dedicated non-Ethernet WAN
144 interface (e.g. DSL/cable/ LTE modem) that
145 would preclude it from operating as an IR.
147 Down Interface a HIPnet router's attachment to a link in
148 the end-user network on which it
149 distributes addresses and/or prefixes.
150 Examples are Ethernet (simple or bridged),
151 802.11 wireless, or other LAN technologies.
152 A HIPnet router may have one or more
153 network-layer down interfaces.
155 downstream router a router directly connected to a HIPnet
156 router's Down Interface.
158 Service Provider an entity that provides access to the
159 Internet. In this document, a service
160 provider specifically offers Internet
161 access using IPv6, and may also offer IPv4
162 Internet access. The service provider can
163 provide such access over a variety of
164 different transport methods such as DSL,
165 cable, wireless, and others.
167 Up Interface a HIPnet router's attachment to a link
168 where it receives one or more IP addresses
169 and/or prefixes. This is also the link to
170 which the HIPnet router points its default
171 route.
173 depth the number of layers of routers in a
174 network. A single router network would
175 have a depth of 1, while a router behind a
176 router behind a router would have a depth
177 of 3.
179 width The number of routers that can be directly
180 subtended to an upstream router. A network
181 with three directly attached routers behind
182 the CER would have a width of 3.
184 3. Architecture
186 3.1. Current End-User Network Architecture
188 An end-user network will likely support both IPv4 and IPv6. A
189 typical end-user network consists of a "plug and play" router with
190 IPv4 NAT functionality and a single link behind it, connected to the
191 service provider network.
193 A typical IPv4 NAT deployment by default blocks all incoming
194 connections. Opening of ports is typically allowed using a Universal
195 Plug and Play Internet Gateway Device (UPnP IGD) [UPNnP-IGD] or some
196 other firewall control protocol.
198 Rewriting addresses on the edge of the network allows for some
199 rudimentary multihoming, even though using NATs for multihoming does
200 not preserve connections during a fail-over event [RFC4864].
202 Many existing routers support dynamic routing, and advanced end-users
203 can build arbitrary, complex networks using manual configuration of
204 address prefixes combined with a dynamic routing protocol.
206 3.2. HIPNet End-User Network Architecture
208 The end-user network architecture should provide equivalent or better
209 capabilities and functionality than the current architecture.
210 However, as end-user networks become more complex, the HIPnet
211 architecture needs to support more complicated networks. Figure 1
212 illustrates the model topology for the end-user network.
214 +-------+-------+ \
215 | Service | \
216 | Provider | | Service
217 | Router | | Provider
218 +-------+-------+ | network
219 | /
220 | Customer /
221 | Internet connection /
222 |
223 +------+--------+ \
224 | IPv6 | \
225 | Customer Edge | \
226 | Router | /
227 +---+-------+-+-+ /
228 Network A | | Network B | End-User
229 ---+-------------+----+- --+--+-------------+--- | network(s)
230 | | | | \
231 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
232 | Host | |Internal | | Host| |Internal | /
233 | | | Router | | | | Router | /
234 +----------+ +-----+----+ +----------+ +----------+ /
235 Network C | Network D | |
236 ---+-------------+----+- --+--+-------------+--- |
237 | | | | \
238 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
239 | Host | | Host | | Host| | Host | /
240 | | | | | | | | /
241 +----------+ +-----+----+ +----------+ +----------+ /
243 Figure 1: Example End-User Network
245 This architecture describes the following:
247 o Prefix subdelegation supporting multiple subnets and routers
249 o Border Detection
251 o Router directionality supporting a hierarchical network
253 o Multicast forwarding rules to support common service discovery
254 protocols
256 While routers described in this document may be manually configured
257 in an arbitrary topology with or without a dynamic routing protocol,
258 this document only addresses automatic provisioning and
259 configuration.
261 4. Network Detection
263 In multirouter home networks, routers have to determine where they
264 fit in the topology - whether they are at the edge or internal, and
265 which interface is up (that is, which interface points out of the
266 network).
268 4.1. Edge Detection
270 Customer Edge Routers (CER) will often be required to behave
271 differently from Internal Routers (IR) in several capacities. Some
272 examples include: Firewall settings, IPv4 NAT, ULA generation (if
273 supported), name services, multicast forwarding differences, and
274 others. This is a functional role, and will not typically be
275 differentiated by hardware/software (i.e. end users will not purchase
276 a specific CER model of router distinct from IR models).
278 There are three methods that a router can use to determine if it is a
279 CER for its given network:
281 "/48 Check" Service providers will provide IPv6 WAN addresses
282 (DHCPv6 IA_NA) and IPv6 prefixes (DHCPv6 IA_PD) from different
283 pools of addresses. The largest IPv6 prefix that we can expect to
284 be delegated to a home router is a /48. Combining these two
285 observations, a home router can compare the WAN address assigned
286 to it with the prefix delegated to it to determine if it is
287 attached directly to a service provider network. If the router is
288 a CER, the WAN address will be from a different /48 than the
289 prefix. If the router is an IR, the WAN address will be from the
290 same /48 as the prefix. In this way, the router can determine if
291 it is recieving an "external" prefix from a service provider or an
292 "internal" prefix from another home router.
294 CER_ID A home router can use the CER_ID DHCPv6 option defined in
295 [I-D.donley-dhc-cer-id-option] to determine if it is a CER or an
296 IR. ISPs will not set the CER_ID option, but the first CPE router
297 sets its address in the option and other routers forward the
298 completed CER_ID to subdelegated routers.
300 Physical Some routers will have a physical differentiator built into
301 them by design that will indicate that they are a CER. Examples
302 include mobile routers, DSL routers, and cable eRouters. In the
303 case of a mobile router, the presence of an active cellular
304 connection indicates that the router is at the customer edge.
305 Likewise, for an eRouter, the presence of an active DOCSIS(R) link
306 tells the router that it is at the customer edge.
308 HIPnet routers can (and likely will) use more than one of the above
309 techniques in combination to determine the edge. For example, an
310 internal router will check for the CER_ID option, but will also use
311 the 48 check in case its upstream router does not support CER_ID.
313 4.2. Directionless Home Routers
315 As home networks grow in complexity and scale, it will become more
316 common for end users to make mistakes with the physical connections
317 between multiple routers in their home or small office. This is
318 liklely to produce loops and improper uplink connections. While we
319 can safely assume that home networks will become more complex over
320 time, we cannot make the same assumption of the users of home
321 networks. Therefor, home routers will need to mitigate these
322 physical topology problems and create a working multi-router home
323 network dynamically, without any end user intervention.
325 Legacy home routers with a physically differentiated uplink port are
326 "directional;" they are pre-set to route from the 'LAN' or Internal
327 ports to a single, pre-defined uplink port labeled "WAN" or
328 "Internet". This means that an end-user can make a cabling mistake
329 which renders the router unusable (e.g. connecting two router's
330 uplink ports together). On the other hand, in enterprise and service
331 provider networks, routers are "directionless;" that is to say they
332 do not have a pre-defined 'uplink' port. While directional routers
333 have a pre-set routing path, directionless routers are required to
334 determine routing paths dynamically. Dynamic routing is often
335 achieved through the implementation of a dynamic routing protocol,
336 which all routers in a given network or network segment must support
337 equally. This section introduces an alternative to dynamic routing
338 protocols (such as OSPF) for creating routing paths on the fly in
339 directionless home routers.
341 Note that some routers (e.g. those with a dedicated wireless/DSL/
342 DOCSIS WAN interface) may continue to operate as directional routers.
343 The HIPnet mechanism described below is intended for general-purpose
344 routers.
346 The HIPnet mechanism uses address acquisition as described in
347 [I-D.ietf-v6ops-6204bis] and various tiebreakers to determine
348 directionality (up vs. down) and by so doing, creates a logical
349 hierarchy (cf. [I-D.chakrabarti-homenet-prefix-alloc]) from any
350 arbitrary physical topology:
352 1. After powering on, the HIPnet router sends Router Solicitations
353 (RS) ([RFC4861]on all interfaces (except Wi-Fi*)
355 2. Other routers respond with Router Advertisements (RA)
357 3. Router adds any interface on which it receives an RA to the
358 candidate 'up' list
360 4. The router initiates DHCPv6 PD on all candidate 'up' interfaces.
361 If no RAs are received, the router generates a /48 ULA prefix.
363 5. The router evaluates the offers received (in order of preference):
365 a) Valid GUA preferred (preferred/valid lifetimes >0)
367 b) Internal prefix preferred over external (for failover - see
368 Section [6.1])
370 c) Largest prefix (e.g. /56 preferred to /60)
372 d) Link type/bandwidth (e.g. Ethernet vs. MoCA)
374 e) First response (wait 1 s after first response for additional
375 offers)
377 f) Lowest numerical prefix
379 6. The router chooses the winning offer as its Up Interface.
381 Once directionality is established, the router continues to listen
382 for RAs on all interfaces but doesn't acquire addresses on Down
383 Interfaces. If the router initially receives only a ULA address on
384 its Up Interface and GUA addressing becomes available on one of its
385 Down Interfaces, it restarts the process. If the router stops
386 receiving RAs on its Up Interface, it restarts the process.
388 In all cases, the router's Up Interface becomes its uplink interface;
389 the router acts as a DHCP client on this interface. The router's
390 remaining interfaces are Down Interfaces; it acts as a DHCP server on
391 these interfaces. Also, per [I-D.ietf-v6ops-6204bis], the router
392 only sends RAs on Down Interfaces.
394 *Note: By default, Wi-Fi interfaces are considered to point "down."
395 This requires manual configuration to enable a wireless uplink, which
396 is preferred to avoid accidental or unwanted linking with nearby
397 wireless networks.
399 5. Routing and Addressing
401 HIPnet routers use DHCPv6 prefix sub-delegation ([RFC3633]) to
402 recursively build a hierarchical network
403 ([I-D.chakrabarti-homenet-prefix-alloc]). This approach requires no
404 new protocols to be supported on any home routers.
406 Default router settings: Only CER instantiates guest network. Wifi
407 defaults to 'down' direction, default route uses wired interface.
408 Firewall considers Wifi an inside port. Wi-Fi bridged with first
409 wired Down Interface.
411 5.1. Recursive Prefix Delegation
413 Once directionality is established, the home router will acquire a
414 WAN IPv6 address and an IPv6 prefix per [I-D.ietf-v6ops-6204bis]. As
415 HIPnet routers (other than the CER) do not know their specific
416 location in the hierarchical network, all HIPnet routers use the same
417 generic rules for recursive prefix delegation to facilitate route
418 aggregation, multihoming, and IPv4 support (described below). This
419 methodology expounds upon that previously described in
420 [I-D.chakrabarti-homenet-prefix-alloc].
422 The process can be illustrated in the following way:
424 1. Per [I-D.ietf-v6ops-6204bis], the HIPnet router assigns a
425 separate /64 from its delegated prefix(es) for each of its Down
426 Interfaces in numerical order, starting from the numerically
427 lowest.
429 2. If the received prefix is too small to number all Down
430 Interfaces, the router collapses them into a single interface,
431 assigns a single /64 to that interface, and logs an error
432 message.
434 3. The HIPnet router subdivides the IPv6 prefix received via DHCPv6
435 ([RFC3315]) into sub-prefixes. To support a suggested depth of
436 three routers, with as large a width as possible, it is
437 recommended to divide the prefix on 2-, 3-, or 4-bit boundaries.
438 If the received prefix is not large enough, it is broken into as
439 many /64 sub-prefixes as possible and logs an error message. By
440 default, this document suggests that the router divide the
441 delegated prefix based on the aggregate prefix size and the
442 HIPnet router's number of physical Down Interfaces. This is to
443 allow for enough prefixes to support a downstream router on each
444 down port.
446 * If the received prefix is smaller than a /56 (e.g. a /60),
448 + 8 or more port routers divide on 3-bit boundaries (e.g.
449 /63).
451 + 7 or fewer port routers divide on 2-bit boundaries (e.g.
452 /62).
454 * If the received prefix is a /56 or larger,
456 + 8 or more port routers divide on 4-bit boundaries (e.g.
457 /60).
459 + 7 or fewer port routers divide on 3-bit boundaries (e.g.
460 /59).
462 4. The HIPnet router delegates remaining prefixes to downstream
463 routers per [RFC3633]in reverse numerical order, starting with
464 the numerically highest. This is to minimize the renumbering
465 impact of enabling an inactive interface.
467 For example, a four port router with two LANs (two Down Interfaces)
468 that receives 2001:db8:0:b0::/60 would start by numbering its two
469 Down Interfaces with 2001:db8:0:b0::/64 and 2001:db8:0:b1::/64
470 respectively, and then begin prefix delegation by giving 2001:db8:0:
471 bc::/62 to the first directly attached downstream router.
473 5.2. Prefix Sub-Delegation Requirements
475 PSD-1: The HIPnet router MUST support [I-D.ietf-v6ops-6204bis]
476 address acquisition and LAN addressing.
478 PSD-2: The HIPnet router MUST support Delegating Router behavior
479 for the IA-PD Option [RFC3633] on all Down Interfaces.
481 PSD-3: HIPnet routers MUST NOT act as both a DHCP client and server
482 on the same link.
484 PSD-4: The HIPnet router MAY support other methods of dividing the
485 received prefix.
487 PSD-5: The HIPnet router MUST delegate prefixes of the same size to
488 downstream routers.
490 PSD-6: Per [I-D.ietf-v6ops-6204bis] L-2, the HIPnet router
491 allocates a /64 to each Down Interface. The HIPnet router
492 SHOULD allocate these /64 interface-prefixes in numerical
493 order, starting with the lowest.
495 PSD-7: If there are insufficient /64s for each Down Interface, the
496 HIPnet router SHOULD assign the lowest numbered /64 for all
497 Down Interfaces and log an error message.
499 PSD-8: The HIPnet router MAY reserve additional /64 interface-
500 prefixes for interfaces that will be enabled in the future.
502 PSD-9: The HIPnet router SHOULD delegate sub-prefixes to downstream
503 routers starting from the numerically highest sub-prefix and
504 working down in reverse numerical order.
506 PSD-10: If there are not enough sub-prefixes remaining to delegate
507 to all downstream routers, the HIPnet router SHOULD log an
508 error message.
510 5.3. Multiple Address Family Support
512 The recursive prefix delegation method described above can be
513 extended to support additional address types such as IPv4, additional
514 GUAs, or ULAs. When the HIPnet router receives its prefix via DHCPv6
515 ([RFC3633]), it computes its 8-bit router ID (bits 56-64) from the
516 received IA_PD. It then prepends additional prefixes received in one
517 or more IPv6 Router Advertisements ([RFC4861]) or from the DHCPv4-
518 assigned ([RFC2131]) IPv4 network address received on the Up
519 Interface.
521 As the network is hierarchical, upstream routers know the router ID
522 for each downstream router, and know the prefix(es) on each LAN
523 segment. Accordingly, HIPnet routers automatically calculate
524 downstream routes to all downstream routers.
526 In networks using this mechanism for IPv4 provisioning, it is
527 suggested that the CER use addresses in the 10.0.0.0/8 ([RFC1918])
528 range for downstream interface provisioning.
530 5.4. Hierarchical Routing
532 The recursive prefix delegation method described above, coupled with
533 "up detection", enables very simple hierarchical routing. By this we
534 mean that each router installs a single default 'up' route and a more
535 specific 'down' route for each prefix delegated to a downstream IR.
536 Each of these 'down' routes simply points all packets destined to a
537 given prefix to the WAN IP address of the router to which that prefix
538 was delegated. This combination of a default 'up' route and more
539 specific 'down' routes provides complete reachability within the home
540 network with no need for any additional message exchange or routing
541 protocol support.
543 6. Multiple ISPs
545 HIPnet routers can support either active/standby multihoming with
546 multiple ISPs or limited active/active multihoming without a routing
547 protocol.
549 6.1. Backup Connection
551 Using the procedure described above, multi-router home networks with
552 multiple ISP connections can easily operate in an active/standby
553 manner, switching from one Internet connection to the other when the
554 active connection fails. Lacking a default priority, HIPnet routers
555 will have to default to a "first online" method of primary CER
556 selection. In other words, by default, the first CER to come online
557 becomes the primary CER and the second CER to turn on becomes the
558 backup. In this text, the primary ISP is the ISP connected to the
559 primary CER and the backup ISP is simply the ISP atached to the
560 backup CER.
562 In an active/standby multi-ISP scenario, a backup CER sets its Up
563 Interface to point to the primary CER, not the backup ISP. Hence, it
564 does not acquire or advertise the backup ISP prefix. Instead, it
565 discovers the internally advertised GUA prefix being distributed by
566 the currently active primary CER.
568 In the case of a primary ISP failure, per [I-D.ietf-v6ops-6204bis],
569 the CER sends an RA advertising the preferred lifetime as 0 for the
570 ISP-provided prefix, and its router lifetime as 0. The backup CER
571 becomes active when it sees the primary ISP GUA prefix advertised
572 with a preferred lifetime of 0. In the case of CER failure, if the
573 backup CER sees the Primary CER stop sending RAs altogether, the
574 Backup CER becomes active.
576 When the backup CER becomes active, it obtains and advertises its own
577 external GUA. When advertising the GUA delegated by its ISP, the
578 backup CER sets the valid, prefered, and router lifetimes to a value
579 greater than 0. Other routers see this and re-determine the network
580 topology via "up" detection, placing the new CER at the root of the
581 new hiearchical tree.
583 Using this approach, manual intervention may be required to
584 transition back to the primary ISP. This prevents flapping in the
585 event of intermittent network failures. Another alternative is to
586 have a user-defined priority, which would facilitate pre-emption.
588 6.2. Multi-homing
590 The HIPnet algorithm also allows for limited active/active
591 multihoming in two cases:
593 1. When one ISP router is used as the primary connection and the
594 second ISP router is used for limited connectivity e.g. for a
595 home office
597 2. When both ISP routers are connected to the same LAN segment at
598 the top of the tree.
600 In case 1, the subscriber has a primary ISP connection and a
601 secondary connection used for a limited special purpose. (e.g. for
602 work VPN, video network, etc.). Devices connected under the
603 secondary network router access the Internet through the secondary
604 ISP. All devices still have access to all network resources in the
605 home. Devices under the secondary connection can use the primary ISP
606 if the secondary fails, but other devices do not use the secondary
607 ISP.
609 +-------+-------+ \
610 | Service | \
611 | Provider | | Service
612 | Router | | Provider
613 +-------+-------+ | network
614 +------------+ | /
615 | ISP 2 | | Customer /
616 +------------+ | Internet connection /
617 | |
618 | +------+--------+ \
619 | | IPv6 | \
620 | | Customer Edge | \
621 | | Router | /
622 | +---+-------+---+ /
623 | Network A | | Network B | End-User
624 | -------+----+- --+--+-------------+--- | network(s)
625 | | | | \
626 | +-----+----+ +----+-----+ +-----+----+ \
627 +-----|Secondary | | Host 1| |Internal | /
628 | CER | | | | Router | /
629 +-----+----+ +----------+ +----------+ /
630 Network C | Network D | |
631 ---+-------------+----+- --+--+-------------+--- |
632 | | | | \
633 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
634 | Host 2| | Host 3 | | Host 4| | Host 5 | /
635 | | | | | | | | /
636 +----------+ +-----+----+ +----------+ +----------+ /
638 Figure 2: An Example of a multihomed End-User Network
640 As described above, the primary CER performs prefix sub-delegation to
641 create the hierarchical tree network. The secondary edge router then
642 obtains a second prefix from ISP2 and advertises the ISP2 prefix as
643 part of its RA. The Secondary CER thus includes sub-prefixes from
644 both ISPs in all IA_PD messages to downstream routers with the same
645 "router id.". In a change from the single-homing (or backup router)
646 case, the secondary CER points its default route to ISP2, and adds an
647 internal /48 route to its upstream internal router (e.g. R1).
648 Devices below the the secondary CER (e.g. Host 2, Host 3) use ISP2,
649 but have full access to all internal devices using the ISP1 prefix
650 (and/or ULAs). If the ISP2 link fails, the secondary CER points its
651 default route 'up' and traffic flows to ISP1. Devices not below the
652 secondary CER (e.g. Hosts 1, 4, 5) use ISP1, but have full access to
653 all internal devices using the ISP1 prefix (or ULAs).
655 In case 2, the secondary CER is installed on the same LAN segment as
656 the primary CER. As above, it acquires a prefix from both the CER
657 and secondary ISP. Since it is on the same LAN segment as the CER,
658 the secondary CER does not delegate prefixes to that interface via
659 DHCP. However, it does generate an RA for the ISP2 prefix on the
660 LAN.
662 As described above, downstream routers receiving the secondary CER RA
663 acquire an address using SLAAC and generate a prefix for sub-
664 delegation by prepending the secondary CER prefix with the router ID
665 generated during the receipt of the prefix from the CER. Such
666 routers then generate their own RAs on downstream interfaces and
667 include the secondary prefix as an IA_PD option in future prefix
668 delegations.
670 6.2.1. Multihoming Requirements
672 MH-1: HIPnet routers configured for active multi-ISP support MUST
673 support DHCP address/prefix acquisition (per
674 [I-D.ietf-v6ops-6204bis] on two interfaces (their WAN and
675 upstream LAN interfaces).
677 MH-2: HIPnet routers configured for active multi-ISP support MAY
678 route packets based on the source IP address of incoming
679 packets using [RFC6724] logic. This allows traffic sourced
680 from the first ISP prefix to be directed to the first ISP, and
681 traffic sourced from the second ISP prefix to be directed to
682 the second ISP.
684 MH-3: HIPnet routers configured for active multi-ISP support MUST
685 advertise RAs for prefixes on all interfaces except the one
686 from which the prefix was acquired or one directly attached to
687 a Service Provider network.
689 7. Mulicast Support
691 7.1. Service Discovery
693 There are several common service discovery protocols such as mDNS
694 [I-D.cheshire-dnsext-multicastdns]/DNS-SD
695 [I-D.cheshire-dnsext-dns-sd] and SSDP [SSDP]. In a multirouter
696 network, service discovery needs to work across the entire home
697 network (e.g. site-scoped rather than link-scoped). This requires
698 that HIPnet routers forward relevant multicast traffic appropriately,
699 to enable service discovery across the home network.
701 7.2. Multicast Proxy Support
703 In addition to multicast support for service discovery, it is
704 recommended that HIPnet routers support external multicast traffic.
706 7.3. Multicast Requirements
708 MULTI-1: A HIPnet router MUST discard IP multicast packets that fail
709 a Reverse Path Forwarding Check (RPFC).
711 MULTI-2: A HIPnet router that determines itself to be at the edge of
712 a home network (e.g. via CER_ID option, /48 verification,
713 or other mechanism) MUST NOT forward IPv4 administratively
714 scoped (239.0.0.0/8) packets onto the WAN interface.
716 MULTI-3: HIPnet Routers MUST forward IPv4 Local Scope multicast
717 packets (239.255.0.0/16) to all LAN interfaces except the
718 one from which they were received.
720 MULTI-4: A HIPnet router that determines itself to be at the edge of
721 a home network (e.g. via CER_ID option, /48 verification,
722 or other mechanism) MUST NOT forward site-scope (FF05::)
723 IPv6 multicast packets onto the WAN interface.
725 MULTI-5: HIPnet routers MUST forward site-scoped (FF05::/16) IPv6
726 multicast packets to all LAN interfaces except the one from
727 which they were received.
729 MULTI-6: A home router MAY discard IP multicast packets sent between
730 Down Interfaces (different VLANs).
732 MULTI-7: HIPnet routers SHOULD support an IGMP/MLD proxy, as
733 described in [RFC4605].
735 8. Firewall Support
737 In a home network, routers need to be equipped with stateful firewall
738 capabilities. Home routers will need to provide "on by default"
739 security where incoming traffic is limited to return traffic
740 resulting from outgoing packets. They also need to allow users to
741 create inbound 'pinholes' for specific purposes, such as online
742 gaming, manually similar to those described in Simple Security
743 ([RFC6092]). "Advanced Security" [I-D.vyncke-advanced-ipv6-security]
744 features optionally could be added to provide intrusion detection
745 (IDS/IPS) support.
747 Local Network Protection for IPv6 [RFC4864] recommends firewall
748 functions that replace NAT security and calls for simple security.
749 Simple Security [RFC6092] defines firewall filtering rules for IPv6
750 traffic. Advanced Security [I-D.vyncke-advanced-ipv6-security]
751 supports the concept of end-to-end IPv6 reachability and uses
752 adaptive filtering based on Intrusion Prevention System (IPS)
753 functions.
755 It is recommended that the CER enable a stateful [RFC6092] firewall
756 by default. IRs have three options described below:
758 IR Firewall Option 1 - Filtering Disabled: Once a home router
759 determines that it is not the CER, it disables its firewall and
760 allows all traffic to pass. The advantages of this approach are that
761 is is simple and easy to troubleshoot and it facilitates whole-home
762 service discovery and media sharing. The disadvantages are that it
763 does not protect home devices from each other (e.g. infected machines
764 could affect entire home network).
766 IR Firewall Option 2 - Simple Security + PCP: Home routers have a
767 [RFC6092] firewall on by default, regardless of CER/IR status but IRs
768 allow "pin-holing" using PCP [I-D.ietf-pcp-base]. CERs can restrict
769 opening PCP pinholes on the up interface. The advantages of this
770 approach are that it protects the home network from internal threats
771 in other LAN segments and it mirrors legacy IPv4 router behavior.
772 The disadvantages to this approach are that it is less predictable;
773 it relies on application "pin-holing", a "default deny" rule that may
774 interfere with service discovery and/or content sharing, and requires
775 PCP clients (e.g. on PCs and CPE devices).
777 IR Firewall Option 3 - Advanced Security: Once a home router
778 determines that it is not the CER, it disables its [RFC6092] firewall
779 but activates an [I-D.vyncke-advanced-ipv6-security] firewall (IPS).
780 The advantages to this approach are that it protects the home network
781 from internal threats in other segments and is more predictable than
782 Option 2, since internal traffic is allowed by default. The
783 disadvantages are that adaptive filtering is more complex than static
784 filtering and typically requires a "fingerprint" subscription to work
785 well.
787 It is recommended that dual-stack routers configure IPv4 support to
788 mirror IPv6, as described above.
790 While this section describes default router behavior, device
791 manufacturers are encouraged to make router security options user-
792 configurable.
794 8.1. Requirements
796 SEC-1: The CER MUST enable a stateful [RFC6092] firewall by default.
798 SEC-2: HIPnet routers MUST only perform IPv4 NAT when serving as the
799 CER.
801 SEC-3: By default, HIPnet routers SHOULD configure IPv4 firewalling
802 rules to mirror IPv6.
804 SEC-4: HIPnet routers serving as CER SHOULD NOT enable UPnP IGD
805 ([UPnP-IGD]) control by default.
807 9. IANA Considerations
809 This document makes no request of IANA.
811 Note to RFC Editor: this section may be removed on publication as an
812 RFC.
814 10. Security Considerations
816 Security considerations are discussed in the Firewall Support section
817 above.
819 11. Acknowledgements
821 TBD
823 12. References
824 12.1. Normative References
826 [I-D.ietf-v6ops-6204bis]
827 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
828 Requirements for IPv6 Customer Edge Routers",
829 draft-ietf-v6ops-6204bis-12 (work in progress),
830 October 2012.
832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
833 Requirement Levels", BCP 14, RFC 2119, March 1997.
835 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
836 and M. Carney, "Dynamic Host Configuration Protocol for
837 IPv6 (DHCPv6)", RFC 3315, July 2003.
839 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
840 Host Configuration Protocol (DHCP) version 6", RFC 3633,
841 December 2003.
843 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
844 "Internet Group Management Protocol (IGMP) / Multicast
845 Listener Discovery (MLD)-Based Multicast Forwarding
846 ("IGMP/MLD Proxying")", RFC 4605, August 2006.
848 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
849 E. Klein, "Local Network Protection for IPv6", RFC 4864,
850 May 2007.
852 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
853 Customer Premises Equipment (CPE) for Providing
854 Residential IPv6 Internet Service", RFC 6092,
855 January 2011.
857 12.2. Informative References
859 [I-D.chakrabarti-homenet-prefix-alloc]
860 Nordmark, E., Chakrabarti, S., Krishnan, S., and W.
861 Haddad, "Simple Approach to Prefix Distribution in Basic
862 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01
863 (work in progress), October 2011.
865 [I-D.cheshire-dnsext-dns-sd]
866 Cheshire, S. and M. Krochmal, "DNS-Based Service
867 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
868 progress), December 2011.
870 [I-D.cheshire-dnsext-multicastdns]
871 Cheshire, S. and M. Krochmal, "Multicast DNS",
872 draft-cheshire-dnsext-multicastdns-15 (work in progress),
873 December 2011.
875 [I-D.donley-dhc-cer-id-option]
876 Donley, C. and C. Grundemann, "Customer Edge Router
877 Identification Option", draft-donley-dhc-cer-id-option-01
878 (work in progress), September 2012.
880 [I-D.ietf-homenet-arch]
881 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
882 "Home Networking Architecture for IPv6",
883 draft-ietf-homenet-arch-07 (work in progress),
884 February 2013.
886 [I-D.ietf-pcp-base]
887 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
888 Selkirk, "Port Control Protocol (PCP)",
889 draft-ietf-pcp-base-29 (work in progress), November 2012.
891 [I-D.vyncke-advanced-ipv6-security]
892 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced
893 Security for IPv6 CPE",
894 draft-vyncke-advanced-ipv6-security-03 (work in progress),
895 October 2011.
897 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
898 E. Lear, "Address Allocation for Private Internets",
899 BCP 5, RFC 1918, February 1996.
901 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
902 RFC 2131, March 1997.
904 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
905 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
906 September 2007.
908 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
909 "Default Address Selection for Internet Protocol Version 6
910 (IPv6)", RFC 6724, September 2012.
912 [SSDP] UPnP Forum, "Universal Plug and Play (UPnP) Device
913 Architecture 1.1", October 2008, .
915 [UPnP-IGD]
916 UPnP Forum, "Universal Plug and Play (UPnP) Internet
917 Gateway Device (IGD)", November 2001,
918 .
920 Authors' Addresses
922 Chris Grundemann
923 CableLabs
924 858 Coal Creek Circle
925 Louisville, CO 80027
926 USA
928 Phone: +1-303-351-1539
929 Email: c.grundemann@cablelabs.com
931 Chris Donley
932 CableLabs
933 858 Coal Creek Circle
934 Louisville, CO 80027
935 USA
937 Email: c.donley@cablelabs.com
939 John Jason Brzozowski
940 Comcast Cable Communications
941 1306 Goshen Parkway
942 Chester, PA 19380
943 USA
945 Email: john_brzozowski@cable.comcast.com
947 Lee Howard
948 Time Warner Cable
949 13241 Woodland Park Rd
950 Herndon, VA 20171
951 USA
953 Email: william.howard@twcable.com
955 Victor Kuarsingh
956 Rogers Communications
957 8200 Dixie Road
958 Brampton, ON L6T 0C1
959 Canada
961 Email: victor.kuarsingh@rci.rogers.com