idnits 2.17.1
draft-grundemann-homenet-hipnet-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 :
----------------------------------------------------------------------------
** 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 15, 2013) is 4089 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'UPNnP-IGD' is mentioned on line 192, but not defined
== Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line
860, 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-06
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 9, 2013 J. Brzozowski
6 Comcast Cable Communications
7 L. Howard
8 Time Warner Cable
9 V. Kuarsingh
10 Rogers Communications
11 February 15, 2013
13 A Near Term Solution for Home IP Networking (HIPnet)
14 draft-grundemann-homenet-hipnet-00
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 9, 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 . . . . . . . . . . . . . . . . . . . . . . 7
74 4.1. Edge Detection . . . . . . . . . . . . . . . . . . . . . . 7
75 4.2. Directionless Home Routers . . . . . . . . . . . . . . . . 8
76 5. Routing and Addressing . . . . . . . . . . . . . . . . . . . . 10
77 5.1. Recursive Prefix Delegation . . . . . . . . . . . . . . . 10
78 5.2. Prefix Sub-Delegation Requirements . . . . . . . . . . . . 11
79 5.3. Multiple Address Family Support . . . . . . . . . . . . . 12
80 5.4. Hierarchical Routing . . . . . . . . . . . . . . . . . . . 13
81 6. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . . . 13
82 6.1. Backup Connection . . . . . . . . . . . . . . . . . . . . 13
83 6.2. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . 14
84 6.2.1. Multihoming Requirements . . . . . . . . . . . . . . . 16
85 7. Mulicast Support . . . . . . . . . . . . . . . . . . . . . . . 16
86 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 16
87 7.2. Multicast Proxy Support . . . . . . . . . . . . . . . . . 16
88 7.3. Multicast Requirements . . . . . . . . . . . . . . . . . . 17
89 8. Firewall Support . . . . . . . . . . . . . . . . . . . . . . . 17
90 8.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
93 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
95 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
96 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 subtended 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 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 a HIPnet router that connects the end-user
134 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 Service Provider an entity that provides access to the
156 Internet. In this document, a service
157 provider specifically offers Internet
158 access using IPv6, and may also offer IPv4
159 Internet access. The service provider can
160 provide such access over a variety of
161 different transport methods such as DSL,
162 cable, wireless, and others.
164 Up Interface a HIPnet router's attachment to a link
165 where it receives one or more IP addresses
166 and/or prefixes. This is also the link to
167 which the HIPnet router points its default
168 route.
170 depth the number of layers of routers in a
171 network. A single router network would
172 have a depth of 1, while a router behind a
173 router behind a router would have a depth
174 of 3.
176 width The number of routers that can be directly
177 subtended to an upstream router. A network
178 with three directly attached routers behind
179 the CER would have a width of 3.
181 3. Architecture
183 3.1. Current End-User Network Architecture
185 An end-user network will likely support both IPv4 and IPv6. A
186 typical end-user network consists of a "plug and play" router with
187 IPv4 NAT functionality and a single link behind it, connected to the
188 service provider network.
190 A typical IPv4 NAT deployment by default blocks all incoming
191 connections. Opening of ports is typically allowed using a Universal
192 Plug and Play Internet Gateway Device (UPnP IGD) [UPNnP-IGD] or some
193 other firewall control protocol.
195 Rewriting addresses on the edge of the network allows for some
196 rudimentary multihoming, even though using NATs for multihoming does
197 not preserve connections during a fail-over event [RFC4864].
199 Many existing routers support dynamic routing, and advanced end-users
200 can build arbitrary, complex networks using manual configuration of
201 address prefixes combined with a dynamic routing protocol.
203 3.2. HIPNet End-User Network Architecture
205 The end-user network architecture should provide equivalent or better
206 capabilities and functionality than the current architecture.
207 However, as end-user networks become more complex, the HIPnet
208 architecture needs to support more complicated networks. Figure 1
209 illustrates the model topology for the end-user network.
211 +-------+-------+ \
212 | Service | \
213 | Provider | | Service
214 | Router | | Provider
215 +-------+-------+ | network
216 | /
217 | Customer /
218 | Internet connection /
219 |
220 +------+--------+ \
221 | IPv6 | \
222 | Customer Edge | \
223 | Router | /
224 +---+-------+-+-+ /
225 Network A | | Network B | End-User
226 ---+-------------+----+- --+--+-------------+--- | network(s)
227 | | | | \
228 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
229 | Host | |Internal | | Host| |Internal | /
230 | | | Router | | | | Router | /
231 +----------+ +-----+----+ +----------+ +----------+ /
232 Network C | Network D | |
233 ---+-------------+----+- --+--+-------------+--- |
234 | | | | \
235 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
236 | Host | | Host | | Host| | Host | /
237 | | | | | | | | /
238 +----------+ +-----+----+ +----------+ +----------+ /
240 Figure 1: An Example of a Typical End-User Network
242 This architecture describes the following:
244 o Prefix subdelegation supporting multiple subnets and routers
246 o Border Detection
248 o Router directionality supporting a hierarchical network
250 o Multicast forwarding rules to support common service discovery
251 protocols
253 While routers described in this document may be manually configured
254 in an arbitrary topology with or without a dynamic routing protocol,
255 this document only addresses automatic provisioning and
256 configuration.
258 4. Network Detection
260 In multirouter home networks, routers have to determine where they
261 fit in the topology - whether they are at the edge or internal, and
262 which interface is up (that is, which interface points out of the
263 network).
265 4.1. Edge Detection
267 Customer Edge Routers (CER) will often be required to behave
268 differently from Internal Routers (IR) in several capacities. Some
269 examples include: Firewall settings, IPv4 NAT, ULA generation (if
270 supported), name services, multicast forwarding differences, and
271 others. This is a functional role, and will not typically be
272 differentiated by hardware/software (i.e. end users will not purchase
273 a specific CER model of router distinct from IR models).
275 There are three methods that a router can use to determine if it is a
276 CER for its given network:
278 "/48 Check" Service providers will provide IPv6 WAN addresses
279 (DHCPv6 IA_NA) and IPv6 prefixes (DHCPv6 IA_PD) from distinct
280 pools of addresses. The largest IPv6 prefix that we can expect to
281 be delegated to a home router is a /48. Combining these two
282 observations, a home router can compare the WAN address assigned
283 to it with the prefix delegated to it to determine if it is
284 attached directly to a service provider network. If the router is
285 a CER, the WAN address will be from a distinct /48 than the
286 prefix. If the router is an IR, the WAN address will be from the
287 same /48 as the prefix. In this way, the router can determine if
288 it is recieving an "external" prefix from a service provider or an
289 "internal" prefix from another home router.
291 CER_ID A home router can use the CER_ID DHCPv6 option defined in
292 [I-D.donley-dhc-cer-id-option] to determine if it is a CER or an
293 IR. ISPs will not set the CER_ID option, but the first CPE router
294 sets its address in the option and other routers forward the
295 completed CER_ID to subdelegated routers.
297 Physical Some routers will have a physical differentiator built into
298 them by design that will indicate that they are a CER. Examples
299 include mobile routers, DSL routers, and cable eRouters. In the
300 case of a mobile router, the presence of an active cellular
301 connection indicates that the router is at the customer edge.
302 Likewise, for an eRouter, the presence of an active DOCSIS(R) link
303 tells the router that it is at the customer edge.
305 HIPnet routers can (and likely will) use more than one of the above
306 techniques in combination to determine the edge. For example, an
307 internal router will check for the CER_ID option, but will also use
308 the 48 check in case its upstream router does not support CER_ID.
310 4.2. Directionless Home Routers
312 As home networks grow in complexity and scale, it will become more
313 common for end users to make mistakes with the physical connections
314 between multiple routers in their home or small office. This is
315 liklely to produce loops and improper uplink connections. While we
316 can safely assume that home networks will become more complex over
317 time, we cannot make the same assumption of the users of home
318 networks. Therefor, home routers will need to mitigate these
319 physical topology problems and create a working multi-router home
320 network dynamically, without any end user intervention.
322 Legacy home routers with a physically differentiated uplink port are
323 "directional;" they are pre-set to route from the 'LAN' or Internal
324 ports to a single, pre-defined uplink port labeled "WAN" or
325 "Internet". This means that an end-user can make a cabling mistake
326 which renders the router unusable (e.g. connecting two router's
327 uplink ports together). On the other hand, in enterprise and service
328 provider networks, routers are "directionless;" that is to say they
329 do not have a pre-defined 'uplink' port. While directional routers
330 have a pre-set routing path, directionless routers are required to
331 determine routing paths dynamically. Dynamic routing is often
332 achieved through the implementation of a dynamic routing protocol,
333 which all routers in a given network or network segment must support
334 equally. This section introduces an alternative to dynamic routing
335 protocols for creating routing paths on the fly in directionless home
336 routers.
338 Note that some routers (e.g. those with a dedicated wireless/DSL/
339 DOCSIS WAN interface) may continue to operate as directional routers.
340 The HIPnet mechanism described below is intended for general-purpose
341 routers.
343 The HIPnet mechanism uses address acquisition as described in
344 [I-D.ietf-v6ops-6204bis] and various tiebreakers to determine
345 directionality (up vs. down) and by so doing, creates a logical
346 hierarchy (cf. [I-D.chakrabarti-homenet-prefix-alloc]) from any
347 arbitrary physical topology:
349 1. After powering on, the HIPnet router sends Router Solicitations
350 (RS) ([RFC4861]on all interfaces (except wifi*)
352 2. Other routers respond with Router Advertisements (RA)
354 3. Router adds any interface on which it receives an RA to the
355 candidate 'up' list
357 4. The router initiates DHCPv6 PD on all candidate 'up' interfaces.
358 If no RAs are received, the router generates a /48 ULA prefix.
360 5. The router evaluates the offers received (in order of preference):
362 a) Valid GUA preferred (preferred/valid lifetimes >0)
364 b) Internal prefix preferred over external (for failover - see
365 Section [[anchor10: 4.3.1]])
367 c) Largest prefix (e.g. /56 preferred to /60)
369 d) Link type/bandwidth (e.g. Ethernet vs. MoCA)
371 e) First response (wait 1 s after first response for additional
372 offers)
374 f) Lowest numerical prefix
376 6. The router chooses the winning offer as its 'up' interface.
378 Once directionality is established, the router continues to listen
379 for RAs on all interfaces but doesn't acquire addresses on 'down'
380 interfaces. If the router initially receives only a ULA address on
381 its 'up' interface and GUA addressing becomes available on one of its
382 'down' interfaces, it restarts the process. If the router stops
383 receiving RAs on its 'up' interface, it restarts the process.
385 In all cases, the router's 'up' interface becomes its uplink
386 interface; the router acts as a DHCP client on this interface. The
387 router's remaining interfaces are 'down' interfaces; it acts as a
388 DHCP server on these interfaces. Also, per [I-D.ietf-v6ops-6204bis],
389 the router only sends RAs on 'down' interfaces.
391 *Note: By default, wifi interfaces are considered to point "down."
392 This requires manual configuration to enable a wireless uplink, which
393 is preferred to avoid accidental or unwanted linking with nearby
394 wireless networks.
396 5. Routing and Addressing
398 HIPnet routers use DHCPv6 prefix sub-delegation ([RFC3633]) to
399 recursively build a hierarchical network
400 ([I-D.chakrabarti-homenet-prefix-alloc]). This approach requires no
401 new protocols to be supported on any home routers.
403 Default router settings: Only CER instantiates guest network. Wifi
404 defaults to 'down' direction, default route uses wired interface.
405 Firewall considers Wifi an inside port. Wifi bridged with first
406 downstream LAN.
408 5.1. Recursive Prefix Delegation
410 Once directionality is established, the home router will acquire a
411 WAN IPv6 address and an IPv6 prefix per [I-D.ietf-v6ops-6204bis]. As
412 HIPnet routers (other than the CER) do not know their specific
413 location in the hierarchical network, all HIPnet routers use the same
414 generic rules for recursive prefix delegation to facilitate route
415 aggregation, multihoming, and IPv4 support (described below). This
416 methodology expounds upon that previously described in
417 [I-D.chakrabarti-homenet-prefix-alloc].
419 The process can be illustrated in the following way:
421 1. Per [I-D.ietf-v6ops-6204bis], the HIPnet router assigns a
422 separate /64 from its delegated prefix(es) for each of its LAN
423 interfaces in numerical order, starting from the numerically
424 lowest.
426 2. If the received prefix is too small to number all 'down'
427 interfaces, the router collapses them into a single interface,
428 assigns a single /64 to that interface, and logs an error
429 message.
431 3. The HIPnet router subdivides the IPv6 prefix received via DHCPv6
432 ([RFC3315]) into sub-prefixes. To support a suggested depth of
433 three routers, with as large a width as possible, it is
434 recommended to divide the prefix on 2-, 3-, or 4-bit boundaries.
435 If the received prefix is not large enough, it is broken into as
436 many /64 sub-prefixes as possible and logs an error message. By
437 default, this document suggests that the router divide the
438 delegated prefix based on the aggregate prefix size and the
439 HIPnet router's number of physical 'down' interfaces. This is to
440 allow for enough prefixes to support a subtended router on each
441 down port.
443 * If the received prefix is smaller than a /56 (e.g. a /60),
445 + 8 or more port routers divide on 3-bit boundaries (e.g.
446 /63).
448 + 7 or fewer port routers divide on 2-bit boundaries (e.g.
449 /62).
451 * If the received prefix is a /56 or larger,
453 + 8 or more port routers divide on 4-bit boundaries (e.g.
454 /60).
456 + 7 or fewer port routers divide on 3-bit boundaries (e.g.
457 /59).
459 4. The HIPnet router delegates remaining prefixes to subtended
460 routers per [RFC3633]in reverse numerical order, starting with
461 the numerically highest. This is to minimize the renumbering
462 impact of enabling an inactive interface.
464 For example, a four port router with two LANs that receives 2001:db8:
465 0:b0::/60 would start by numbering its two 'down' IP interfaces with
466 2001:db8:0:b0::/64 and 2001:db8:0:b1::/64 respectively, and then
467 begin prefix delegation by giving 2001:db8:0:bc::/62 to the first
468 directly attached downstream router.
470 5.2. Prefix Sub-Delegation Requirements
472 PSD-1: The HIPnet router MUST support [I-D.ietf-v6ops-6204bis]
473 address acquisition and LAN addressing.
475 PSD-2: The HIPnet router MUST support Delegating Router behavior
476 for the IA-PD Option [RFC3633] on all 'down' interfaces.
478 PSD-3: HIPnet routers MUST NOT act as both a DHCP client and server
479 on the same link.
481 PSD-4: The HIPnet router MAY support other methods of dividing the
482 received prefix.
484 PSD-5: The HIPnet router MUST delegate prefixes of the same size to
485 subtended routers.
487 PSD-6: Per [I-D.ietf-v6ops-6204bis] L-2, the HIPnet router
488 allocates a /64 to each 'down' interface. The HIPnet router
489 SHOULD allocate these /64 interface-prefixes in numerical
490 order, starting with the lowest.
492 PSD-7: If there are insufficient /64s for each 'down' interface,
493 the HIPnet router SHOULD assign a single /64 for all 'down'
494 IP interfaces and log an error message.
496 PSD-8: The HIPnet router MAY reserve additional /64 interface-
497 prefixes for interfaces that will be enabled in the future.
499 PSD-9: The HIPnet router SHOULD delegate sub-prefixes to subtended
500 routers starting from the numerically highest sub-prefix and
501 working down in reverse numerical order.
503 PSD-10: If there are not enough sub-prefixes remaining to delegate
504 to all downstream routers, the HIPnet router SHOULD log an
505 error message.
507 5.3. Multiple Address Family Support
509 The recursive prefix delegation method described above can be
510 extended to support additional address types such as IPv4, additional
511 GUAs, or ULAs. When the HIPnet router receives its prefix via DHCPv6
512 ([RFC3633]), it computes its 8-bit router ID (bits 56-64) from the
513 received IA_PD. It then prepends additional prefixes received in one
514 or more IPv6 Router Advertisements ([RFC4861]) or from the DHCPv4-
515 assigned ([RFC2131]) IPv4 network address received on the 'up'
516 interface.
518 As the network is hierarchical, upstream routers know the router ID
519 for each downstream router, and know the prefix(es) on each LAN
520 segment. Accordingly, HIPnet routers automatically calculate
521 downstream routes to all subtended routers.
523 In networks using this mechanism for IPv4 provisioning, it is
524 suggested that the CER use addresses in the 10.0.0.0/8 ([RFC1918])
525 range for downstream interface provisioning.
527 5.4. Hierarchical Routing
529 The recursive prefix delegation method described above, coupled with
530 "up detection", enables very simple hierarchical routing. By this we
531 mean that each router installs a single default 'up' route and a more
532 specific 'down' route for each prefix delegated to a downstream IR.
533 Each of these 'down' routes simply points all packets destined to a
534 given prefix to the WAN IP address of the router to which that prefix
535 was delegated. This combination of a default 'up' route and more
536 specific 'down' routes provides complete reachability within the home
537 network with no need for any additional message exchange or routing
538 protocol support.
540 6. Multiple ISPs
542 HIPnet routers can support either active/standby multihoming with
543 multiple ISPs or limited active/active multihoming without a routing
544 protocol.
546 6.1. Backup Connection
548 Using the procedure described above, multi-router home networks with
549 multiple ISP connections can easily operate in an active/standby
550 manner, switching from one Internet connection to the other when the
551 active connection fails.
553 In an active/standby multi-ISP scenario, a backup CER sets its 'up'
554 interface to point to the primary CER, not the backup ISP. Hence, it
555 does not acquire or advertise the Backup ISP prefix. Instead, it
556 discovers the internally advertised GUA prefix being distributed by
557 the currently active primary CER.
559 In the case of a primary ISP failure, per [I-D.ietf-v6ops-6204bis],
560 the CER sends an RA advertising the preferred lifetime as 0 for the
561 ISP-provided prefix, and its router lifetime as 0. The Backup CER
562 becomes active when it sees the primary ISP GUA prefix advertised
563 with a preferred lifetime of 0. In the case of CER failure, if the
564 Backup CER sees the Primary CER stop sending RAs altogether, the
565 Backup CER becomes active.
567 When the Backup CER becomes active, it obtains and advertises its own
568 external GUA. When advertising the GUA delegated by its ISP, the
569 Backup CER sets the valid, prefered, and router lifetimes to a value
570 greater than 0. Other routers see this and re-determine the network
571 topology via "up" detection, placing the new CER at the root of the
572 new hiearchical tree.
574 Using this approach, manual intervention may be required to
575 transition back to the primary ISP. This prevents flapping in the
576 event of intermittent network failures.
578 6.2. Multi-homing
580 The HIPnet algorithm also allows for limited active/active
581 multihoming in two cases:
583 1. When one ISP router is used as the primary connection and the
584 second ISP router is used for limited connectivity e.g. for a
585 home office
587 2. When both ISP routers are connected to the same LAN segment at
588 the top of the tree.
590 In case 1, the subscriber has a primary ISP connection and a
591 secondary connection used for a limited special purpose. (e.g. for
592 work VPN, video network, etc.). Devices connected under the
593 secondary network router access the Internet through the secondary
594 ISP. All devices still have access to all network resources in the
595 home. Devices under the secondary connection can use the primary ISP
596 if the secondary fails, but other devices do not use the secondary
597 ISP.
599 +-------+-------+ \
600 | Service | \
601 | Provider | | Service
602 | Router | | Provider
603 +-------+-------+ | network
604 +------------+ | /
605 | ISP 2 | | Customer /
606 +------------+ | Internet connection /
607 | |
608 | +------+--------+ \
609 | | IPv6 | \
610 | | Customer Edge | \
611 | | Router | /
612 | +---+-------+---+ /
613 | Network A | | Network B | End-User
614 | -------+----+- --+--+-------------+--- | network(s)
615 | | | | \
616 | +-----+----+ +----+-----+ +-----+----+ \
617 +-----|Secondary | | Host 1| |Internal | /
618 | CER | | | | Router | /
619 +-----+----+ +----------+ +----------+ /
620 Network C | Network D | |
621 ---+-------------+----+- --+--+-------------+--- |
622 | | | | \
623 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \
624 | Host 2| | Host 3 | | Host 4| | Host 5 | /
625 | | | | | | | | /
626 +----------+ +-----+----+ +----------+ +----------+ /
628 Figure 2: An Example of a multihomed End-User Network
630 As described above, the primary CER performs prefix sub-delegation to
631 create the hierarchical tree network. The secondary edge router then
632 obtains a second prefix from ISP2 and advertises the ISP2 prefix as
633 part of its RA. The Secondary CER thus includes sub-prefixes from
634 both ISPs in all IA_PD messages to downstream routers with the same
635 "router id.". In a change from the single-homing (or backup router)
636 case, the secondary CER points its default route to ISP2, and adds an
637 internal /48 route to its upstream internal router (e.g. R1).
638 Devices below the the secondary CER (e.g. Host 2, Host 3) use ISP2,
639 but have full access to all internal devices using the ISP1 prefix
640 (and/or ULAs). If the ISP2 link fails, the secondary CER points its
641 default route 'up' and traffic flows to ISP1. Devices not below the
642 secondary CER (e.g. Hosts 1, 4, 5) use ISP1, but have full access to
643 all internal devices using the ISP1 prefix (or ULAs).
645 In case 2, the secondary CER is installed on the same LAN segment as
646 the primary CER. As above, it acquires a prefix from both the CER
647 and secondary ISP. Since it is on the same LAN segment as the CER,
648 the secondary CER does not delegate prefixes to that interface via
649 DHCP. However, it does generate an RA for the ISP2 prefix on the
650 LAN.
652 As described above, downstream routers receiving the secondary CER RA
653 acquire an address using SLAAC and generate a prefix for sub-
654 delegation by prepending the secondary CER prefix with the router ID
655 generated during the receipt of the prefix from the CER. Such
656 routers then generate their own RAs on downstream interfaces and
657 include the secondary prefix as an IA_PD option in future prefix
658 delegations.
660 6.2.1. Multihoming Requirements
662 MH-1: HIPnet routers configured for active multi-ISP support MUST
663 support DHCP address/prefix acquisition (per
664 [I-D.ietf-v6ops-6204bis] on two interfaces (their WAN and
665 upstream LAN interfaces).
667 MH-2: HIPnet routers configured for active multi-ISP support MAY
668 route packets based on the source IP address of incoming
669 packets using [RFC6724] logic. This allows traffic sourced
670 from the first ISP prefix to be directed to the first ISP, and
671 traffic sourced from the second ISP prefix to be directed to
672 the second ISP.
674 MH-3: HIPnet routers configured for active multi-ISP support MUST
675 advertise RAs for prefixes on all interfaces except the one
676 from which the prefix was acquired or one directly attached to
677 a Service Provider network.
679 7. Mulicast Support
681 7.1. Service Discovery
683 There are several common service discovery protocols such as mDNS
684 [I-D.cheshire-dnsext-multicastdns]/DNS-SD
685 [I-D.cheshire-dnsext-dns-sd] and SSDP [SSDP]. In a multirouter
686 network, service discovery needs to work across the entire home
687 network (e.g. site-scoped rather than link-scoped).
689 7.2. Multicast Proxy Support
691 In addition to multicast support for service discovery, it is
692 recommended that HIPnet routers support external multicast traffic.
694 7.3. Multicast Requirements
696 MULTI-1: A HIPnet router MUST discard IP multicast packets that fail
697 a Reverse Path Forwarding Check (RPFC).
699 MULTI-2: A home router MAY discard IP multicast packets sent between
700 'guest' and 'internal' networks.
702 MULTI-3: A HIPnet router that determines itself to be at the edge of
703 a home network (e.g. via CER_ID option, /48 verification,
704 or other mechanism) MUST NOT forward IPv4 administratively
705 scoped (239.0.0.0/8) packets onto the WAN interface.
707 MULTI-4: HIPnet Routers MUST forward IPv4 Local Scope multicast
708 packets (239.255.0.0/16) to all LAN interfaces except the
709 one from which they were received.
711 MULTI-5: 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 link-scope (FF02::) or
714 site-scope (FF05::) IPv6 multicast packets onto the WAN
715 interface.
717 MULTI-6: HIPnet routers MUST forward site-scoped (FF05::/16) IPv6
718 multicast packets to all LAN interfaces except the one from
719 which they were received.
721 MULTI-7: HIPnet routers SHOULD support an IGNMP/MLD proxy, as
722 described in [RFC4605].
724 8. Firewall Support
726 In a home network, routers need to be equipped with stateful firewall
727 capabilities. Home routers will need to provide "on by default"
728 security where incoming traffic is limited to return traffic
729 resulting from outgoing packets. They also need to allow users to
730 create inbound 'pinholes' for specific purposes, such as online
731 gaming, manually similar to those described in Simple Security
732 ([RFC6092]). "Advanced Security" [I-D.vyncke-advanced-ipv6-security]
733 features optionally could be added to provide intrusion detection
734 (IDS/IPS) support.
736 Local Network Protection for IPv6 [RFC4864] recommends firewall
737 functions that replace NAT security and calls for simple security.
738 Simple Security [RFC6092] defines firewall filtering rules for IPv6
739 traffic. Advanced Security [I-D.vyncke-advanced-ipv6-security]
740 supports the concept of end-to-end IPv6 reachability and uses
741 adaptive filtering based on Intrusion Prevention System (IPS)
742 functions.
744 It is recommended that the CER enable a stateful [RFC6092] firewall
745 by default. IRs have three options described below:
747 IR Firewall Option 1 - Filtering Disabled: Once a home router
748 determines that it is not the CER, it disables its firewall and
749 allows all traffic to pass. The advantages of this approach are that
750 is is simple and easy to troubleshoot and it facilitates whole-home
751 service discovery and media sharing. The disadvantages are that it
752 does not protect home devices from each other (e.g. infected machines
753 could affect entire home network).
755 IR Firewall Option 2 - Simple Security + PCP: Home routers have a
756 [RFC6092] firewall on by default, regardless of CER/IR status but IRs
757 allow "pin-holing" using PCP [I-D.ietf-pcp-base]. CERs can restrict
758 opening PCP pinholes on the up interface. The advantages of this
759 approach are that it protects the home network from internal threats
760 in other LAN segments and it mirrors legacy IPv4 router behavior.
761 The disadvantages to this approach are that it is less predictable;
762 it relies on application "pin-holing", a "default deny" rule that may
763 interfere with service discovery and/or content sharing, and requires
764 PCP clients (e.g. on PCs and CPE devices).
766 IR Firewall Option 3 - Advanced Security: Once a home router
767 determines that it is not the CER, it disables its [RFC6092] firewall
768 but activates an [I-D.vyncke-advanced-ipv6-security] firewall (IPS).
769 The advantages to this approach are that it protects the home network
770 from internal threats in other segments and is more predictable than
771 Option 2, since internal traffic is allowed by default. The
772 disadvantages are that adaptive filtering is more complex than static
773 filtering and typically requires a "fingerprint" subscription to work
774 well.
776 It is recommended that dual-stack routers configure IPv4 support to
777 mirror IPv6, as described above.
779 While this section describes default router behavior, device
780 manufacturers are encouraged to make router security options user-
781 configurable.
783 8.1. Requirements
784 SEC-1: The CER SHOULD enable a stateful [RFC6092] firewall by
785 default.
787 SEC-2: HIPnet routers SHOULD only perform IPv4 NAT when serving as
788 the CER.
790 SEC-3: By default, HIPnet routers SHOULD configure IPv4 firewalling
791 rules to mirror IPv6.
793 SEC-4: HIPnet routers serving as CER SHOULD NOT enable UPnP IGD
794 ([UPnP-IGD]) control by default.
796 9. IANA Considerations
798 This document makes no request of IANA.
800 Note to RFC Editor: this section may be removed on publication as an
801 RFC.
803 10. Security Considerations
805 Security considerations are discussed in the Firewall Support section
806 above.
808 11. Acknowledgements
810 TBD
812 12. References
814 12.1. Normative References
816 [I-D.ietf-v6ops-6204bis]
817 Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
818 Requirements for IPv6 Customer Edge Routers",
819 draft-ietf-v6ops-6204bis-12 (work in progress),
820 October 2012.
822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
823 Requirement Levels", BCP 14, RFC 2119, March 1997.
825 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
826 and M. Carney, "Dynamic Host Configuration Protocol for
827 IPv6 (DHCPv6)", RFC 3315, July 2003.
829 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
830 Host Configuration Protocol (DHCP) version 6", RFC 3633,
831 December 2003.
833 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
834 "Internet Group Management Protocol (IGMP) / Multicast
835 Listener Discovery (MLD)-Based Multicast Forwarding
836 ("IGMP/MLD Proxying")", RFC 4605, August 2006.
838 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
839 E. Klein, "Local Network Protection for IPv6", RFC 4864,
840 May 2007.
842 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
843 Customer Premises Equipment (CPE) for Providing
844 Residential IPv6 Internet Service", RFC 6092,
845 January 2011.
847 12.2. Informative References
849 [I-D.chakrabarti-homenet-prefix-alloc]
850 Nordmark, E., Chakrabarti, S., Krishnan, S., and W.
851 Haddad, "Simple Approach to Prefix Distribution in Basic
852 Home Networks", draft-chakrabarti-homenet-prefix-alloc-01
853 (work in progress), October 2011.
855 [I-D.cheshire-dnsext-dns-sd]
856 Cheshire, S. and M. Krochmal, "DNS-Based Service
857 Discovery", draft-cheshire-dnsext-dns-sd-11 (work in
858 progress), December 2011.
860 [I-D.cheshire-dnsext-multicastdns]
861 Cheshire, S. and M. Krochmal, "Multicast DNS",
862 draft-cheshire-dnsext-multicastdns-15 (work in progress),
863 December 2011.
865 [I-D.donley-dhc-cer-id-option]
866 Donley, C. and C. Grundemann, "Customer Edge Router
867 Identification Option", draft-donley-dhc-cer-id-option-01
868 (work in progress), September 2012.
870 [I-D.ietf-homenet-arch]
871 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
872 "Home Networking Architecture for IPv6",
873 draft-ietf-homenet-arch-06 (work in progress),
874 October 2012.
876 [I-D.ietf-pcp-base]
877 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
878 Selkirk, "Port Control Protocol (PCP)",
879 draft-ietf-pcp-base-29 (work in progress), November 2012.
881 [I-D.vyncke-advanced-ipv6-security]
882 Vyncke, E., Yourtchenko, A., and M. Townsley, "Advanced
883 Security for IPv6 CPE",
884 draft-vyncke-advanced-ipv6-security-03 (work in progress),
885 October 2011.
887 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
888 E. Lear, "Address Allocation for Private Internets",
889 BCP 5, RFC 1918, February 1996.
891 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
892 RFC 2131, March 1997.
894 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
895 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
896 September 2007.
898 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
899 "Default Address Selection for Internet Protocol Version 6
900 (IPv6)", RFC 6724, September 2012.
902 [SSDP] UPnP Forum, "Universal Plug and Play (UPnP) Device
903 Architecture 1.1", October 2008, .
905 [UPnP-IGD]
906 UPnP Forum, "Universal Plug and Play (UPnP) Internet
907 Gateway Device (IGD)", November 2001,
908 .
910 Authors' Addresses
912 Chris Grundemann
913 CableLabs
914 858 Coal Creek Circle
915 Louisville, CO 80027
916 USA
918 Phone: +1-303-351-1539
919 Email: c.grundemann@cablelabs.com
920 Chris Donley
921 CableLabs
922 858 Coal Creek Circle
923 Louisville, CO 80027
924 USA
926 Email: c.donley@cablelabs.com
928 John Jason Brzozowski
929 Comcast Cable Communications
930 1306 Goshen Parkway
931 Chester, PA 19380
932 USA
934 Email: john_brzozowski@cable.comcast.com
936 Lee Howard
937 Time Warner Cable
938 13241 Woodland Park Rd
939 Herndon, VA 20171
940 USA
942 Email: william.howard@twcable.com
944 Victor Kuarsingh
945 Rogers Communications
946 8200 Dixie Road
947 Brampton, ON L6T 0C1
948 Canada
950 Email: victor.kuarsingh@rci.rogers.com