Internet DRAFT - draft-howard-homenet-routing-comparison
draft-howard-homenet-routing-comparison
homenet L. Howard
Internet-Draft Time Warner Cable
Intended status: Informational December 29, 2011
Expires: July 1, 2012
Evaluation of Proposed Homenet Routing Solutions
draft-howard-homenet-routing-comparison-00
Abstract
This document evaluates the various proposals for routing in an
unmanaged home network.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 1, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Howard Expires July 1, 2012 [Page 1]
Internet-Draft Homenet Routing Comparison December 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. UP-PIO . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. MANEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. new section . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Howard Expires July 1, 2012 [Page 2]
Internet-Draft Homenet Routing Comparison December 2011
1. Introduction
This document evaluates the suitability of each of the proposed
routing solutions for the Homenet problem space. The list of
requirements is provided in
[draft-howard-homenet-routing-requirements] (soon to be included in
[draft-ietf-homenet-arch]). This document is intended to assist the
working group in developing consensus around a single solution, so
that work may progress.
2. Requirements
This section includes the requirements from
[draft-howard-homenet-routing-requirements]. After each requirement
is a short mnemonic, to be used in the table comparing each solution.
1. Reachability between all nodes in the home network. Links may
be Ethernet, WiFi, MoCA, or any other; test all solutions
against mutliple L2 types. [1. Reachability]
2. Border detection. Any solution will have to determine the
routing boundary. It is assumed that no home networking device
can handle a full routing table for the Internet, and that a
home router should not be required to do so. [2. Border
detection]
A. Border may be upstream ISP, or may be a device that is a
gateway to SmartGrid devices, e.g. a controller that speaks
RPL to 802.15.4 and foo to home net. Or there may be no
border, if no external connection has been established. [2a.
Any border]
B. Must be able to find "up" (a path to the Internet), but must
not be dependent on "up" (Internet connectivity) existing
for intra-home reachability. [2b. Find "up"]
C. May be discovered by routing protocol, or other means. [2c.
Border method]
3. Robust to routers being moved/added/removed/renumbered.
Convergence time a few minutes or less. [3. Handles change]
4. No configuration required. It may be acceptable to require a
single password or passphrase to be entered on each device, both
for security, and to establish the administrative boundary. [4.
No config]
Howard Expires July 1, 2012 [Page 3]
Internet-Draft Homenet Routing Comparison December 2011
5. Best-path is a non-requirement. [5. Null requirement]
6. Support for multiple upstream networks is a requirement. [6.
Multiple upstreams]
A. Including wireless offload, video-only, and split-tunnel VPN
scenarios. [6a. Split up views]
B. It may be assumed that each upstream will be connected via a
separate router, not multihomed off the same router. [6b.
Null requirement]
C. Must support a prefix delegated from each provider. How
hosts handle multiple prefixes is not a routing problem.
[6c. Multiple PD]
D. Load-balancing among providers is a non-requirement. [6d.
Null requirement]
E. If multiple upstream networks can provide a path to the same
destination (such as an Internet host), the solution must
allow for backup in case the router or link to one upstream
fails. Failover time should be within a few minutes. [6e.
Failover]
F. Must support a "walled-garden" network. This might routing
based on either source address (from the walled garden
network) or destination address (to the walled garden
network); support for both is not required. [6f. Walled
garden]
G. Source address selection is out of scope for the routing
solution. Choosing which address to use to look up the
destination address is out of scope for the routing
solution. [6g. Null requirement]
7. Cannot assume hierarchical prefix delegation in the home, unless
the Homenet working group finds consensus on a hierarchical
addressing mechanism. [7. Non-hierarchical]
8. A host with mutliple upstream paths to the same destination (in-
home or external) should be able to use another in case on
fails. [8. Failover]
9. Prevent looping. [9. Prevent loops]
10. Should be a lightweight solution. [10. Lightweight]
Howard Expires July 1, 2012 [Page 4]
Internet-Draft Homenet Routing Comparison December 2011
11. Must handle multi-dwelling units or other potential dense
wireless or wired networks. [11. Robust to MDUs]
12. Must be resilient to running on wireless networks. Must be able
to handle both wired and wireless links. [12. Wireless]
13. Robustness in the face of unintentional joining of networks.
[12. Unintended joins]
3. Consideration
3.1. OSPFv3
As documented in [OSPFv3-autoconfig].
1. Reachability. YES, OSPF can detect reachability.
2. Border detection. NO. Any node which the router uses as a next
hop, but which is not in its OSPF Area 0, may be assumed to be
an external border. However, the router will have to be
manually configured, or use another routing protocol, to
establish a path to that next hop; therefore auto-configured
OSPFv3 by itself does not detect borders.
A. Any border. NO.
B. Find "up". NO. Manual configuration of the router
neighboring the ISP is required to set a default route.
C. Border method. MANUAL.
3. Handles change. YES. OSPFv3 normally handles router additions
and removals well, with link-state changes. It may not be able
to handle being moved from one existing segment to another.
4. No config. YES, but requires manual configuration for security.
5. (null)
6. Multiple upstreams. YES, OSPFv3 can support multiple default
routes, and multiple specific routes.
A. Split up views. SOMEWHAT. OSPFv3 can certainly carry many
paths, including specific routes for a wireles home agent,
video cluster, or VPN concentrator. It cannot, by itself,
establish routing policies determining which hosts may use
those paths, so the upstream ISP may not have a return path
Howard Expires July 1, 2012 [Page 5]
Internet-Draft Homenet Routing Comparison December 2011
(or may have an asymmetric path).
B. (null)
C. Multiple PD. YES, OSPFv3 can route for multiple prefixes on
a link.
D. (null)
E. Failover. YES, autoconfigured OSPFv3 detects link state
change and reconverges in a reasonable amount of time.
F. Walled garden. SOMEWHAT. OSPFv3 can carry destination
routes, but cannot by itself support source-based routing.
G. (null)
7. Non-hierarchical addressing. YES.
8. Failover. YES.
9. Prevent loops. YES.
10. Lightweight. NO. One estimate of a common implementation is
50,000 lines of code.
11. Robust to MDUs. YES. Full LSAs are sent periodically, but they
are not onerus.
12. Wireless. YES.
13. Unintended joins. NO. Autoconfig OSPFv3 is not resilient
against unintended joins unless the recommendation to use
authentication hashes [OSPFV3-AUTH-TRAILER] is followed, which
requires manual configuration.
3.2. RIPng
Specified in [RFC2080], but no document specifying how it would be
used in a Homenet environment has been written.
1. Reachability. YES, RIPng can detect reachability.
2. Border detection. NO. Any node which the router uses as a next
hop, but which is not speaking RIPng, may be assumed to be an
external border. However, the router will have to be manually
configured, or use another routing protocol, to establish a path
to that next hop; therefore auto-configured RIPng by itself does
Howard Expires July 1, 2012 [Page 6]
Internet-Draft Homenet Routing Comparison December 2011
not detect borders.
A. Any border. NO. Some ISPs use RIP (though rarely RIPng) to
communicate with customers.
B. Find "up". NO. Manual configuration of the router
neighboring the ISP is required to set a default route.
C. Border method. MANUAL.
3. Handles change. YES. RIPng normally handles router additions
and removals. It may not be able to handle being moved from one
existing segment to another.
4. No config. YES.
5. (null)
6. Multiple upstreams. NO, RIPng does not forward to multiple
paths for the same prefix.
A. Split up views. YES, RIPng can carry multiple paths,
including specific routes for a wireles home agent, video
cluster, or VPN concentrator. It cannot, by itself,
establish routing policies determining which hosts may use
those paths, so the upstream ISP may not have a return path
(or may have an asymmetric path).
B. (null)
C. Multiple PD. Yes, RIPng can support multiple prefixes on a
link.
D. (null)
E. Failover. Yes, RIPng can calculate a new path when one is
lost or withdrawn.
F. Walled garden. SOMEWHAT. RIPng can carry destination
routes, but cannot by itself support source-based routing.
G. (null)
7. Non-hierarchical addressing. YES.
8. Failover. YES.
Howard Expires July 1, 2012 [Page 7]
Internet-Draft Homenet Routing Comparison December 2011
9. Prevent loops. SOMEWHAT. RIPng uses the original RIP count-to-
infinity algorithm to prevent infinite loops; it works, but is
inefficient, especially in larger networks.
10. Lightweight. YES.
11. Robust to MDUs. YES.
12. Wireless. YES.
13. Unintended joins. NO. There is no authorization method;
[RFC2080] says to use the Authentication Header built into IPv6,
which would allow any RIPng host.
3.3. UP-PIO
As documented in [UP-PIO], this proposal would overload Router
Advertisements to apporximate a distance-vector routing protocol.
1. Reachability. YES, UP-PIO will find a path, but it may not be
the shortest path.
2. Border detection. YES. UP-PIO infers from DHCP-PD where the
ISP network is.
A. Any border. YES. A dedicated gateway, intended to run
between an 802.15.4 network and a Wi-Fi or Ethernet (etc.)
segment on a Homenet network, could be preconfigured to
establish itself as UP for that prefix.
B. Find "up". YES.
C. Border method. Assume that DHCP-PD indicates upstream ISP,
increment distance with RAs.
3. Handles change. YES, UP handles moves/adds/changes/deletions
exactly as well as Router Advertisements do.
4. No config. YES.
5. (null)
6. Multiple upstreams. YES, whatever information is included in
RAs is propagated.
A. Split up views. YES.
Howard Expires July 1, 2012 [Page 8]
Internet-Draft Homenet Routing Comparison December 2011
B. (null)
C. Multiple PD. YES.
D. (null)
E. Failover.
F. Walled garden. YES.
G. (null)
7. Non-hierarchical addressing. NO. UP depends on hierarchical
addressing.
8. Failover. YES, when RAs are no longer detected, an alternate
path is computed.
9. Prevent loops. Undefined; the protocol is still being defined.
It is expected to prevent loops as well as RIPng.
10. Lightweight. YES.
11. Robust to MDUs. YES.
12. Wireless. YES.
13. Unintended joins. NO. Even SEND would only authenticate, not
authorize.
3.4. IS-IS
As defined in [RFC1195], but no document specifying how it would be
used in a Homenet environment has been written.
1. Reachability. YES.
2. Border detection. NO. Any node which the router uses as a next
hop, but which is not speaking IS-IS, may be assumed to be an
external border. However, the router will have to be manually
configured, or use another routing protocol, to establish a path
to that next hop; therefore auto-configured IS-IS by itself does
not detect borders.
A. Any border. NO.
B. Find "up". NO. Manual configuration of the router
neighboring the ISP is required to set a default route.
Howard Expires July 1, 2012 [Page 9]
Internet-Draft Homenet Routing Comparison December 2011
C. Border method. MANUAL.
3. Handles change. YES.
4. No config. NO, IS-IS must be configured.
5. (null)
6. Multiple upstreams. YES.
A. Split up views. YES.
B. (null)
C. Multiple PD. YES.
D. (null)
E. Failover. YES.
F. Walled garden. YES.
G. (null)
7. Non-hierarchical addressing. YES.
8. Failover. YES.
9. Prevent loops. YES.
10. Lightweight. NO.
11. Robust to MDUs. YES.
12. Wireless. YES.
13. Unintended joins. SOMEWHAT, if [RFC5310] is implemented, but
that requires further manual configuration.
3.5. MANEMO
No document exists describing this mechanism, though several people
have suggested it to the working group. Evaluation will have to be
undertaken by someone familiar with the mechanism.
1. Reachability
Howard Expires July 1, 2012 [Page 10]
Internet-Draft Homenet Routing Comparison December 2011
2. Border detection
A. Any border.
B. Find "up".
C. Border method.
3. Handles change.
4. No config
5. (null)
6. Multiple upstreams.
A. Split up views.
B. (null)
C. Multiple PD.
D. (null)
E. Failover.
F. Walled garden.
G. (null)
7. Non-hierarchical addressing.
8. Failover.
9. Prevent loops.
10. Lightweight.
11. Robust to MDUs.
12. Wireless.
13. Unintended joins.
Howard Expires July 1, 2012 [Page 11]
Internet-Draft Homenet Routing Comparison December 2011
3.6. RPL
As documented in [RPL], but no document specifying how it would be
used in a Homenet environment has been written.
1. Reachability. YES.
2. Border detection. NO.
A. Any border. NO.
B. Find "up". NO.
C. Border method. NO.
3. Handles change. YES.
4. No config. YES?
5. (null)
6. Multiple upstreams.
A. Split up views.
B. (null)
C. Multiple PD.
D. (null)
E. Failover.
F. Walled garden.
G. (null)
7. Non-hierarchical addressing.
8. Failover.
9. Prevent loops.
10. Lightweight. YES.
11. Robust to MDUs.
Howard Expires July 1, 2012 [Page 12]
Internet-Draft Homenet Routing Comparison December 2011
12. Wireless.
13. Unintended joins.
3.7. new section
+-------------+--------+--------+--------+--------+--------+-----+
| Requirement | OSPFv3 | RIPng | UP PIO | IS-IS | MANEMO | RPL |
+-------------+--------+--------+--------+--------+--------+-----+
| 1. | YES | YES | YES | YES | | |
| 2. | NO | NO | YES | NO | | |
| 2A. | NO | NO | YES | NO | | |
| 2B. | NO | NO | YES | NO | | |
| 2C. | MANUAL | MANUAL | PD | MANUAL | | |
| 3. | YES | YES | YES | YES | | |
| 4. | YES | YES | YES | NO | | |
| 5. | NA | NA | NA | NA | | |
| 6. | YES | NO | YES | YES | | |
| 6A. | SOME | YES | YES | YES | | |
| 6B. | NA | NA | NA | NA | | |
| 6C. | YES | YES | YES | YES | | |
| 6D. | NA | NA | NA | NA | | |
| 6E. | YES | YES | YES | YES | | |
| 6F. | SOME | SOME | YES | YES | | |
| 6G. | NA | NA | NA | NA | | |
| 7. | YES | YES | NO | YES | | |
| 8. | YES | YES | YES | YES | | |
| 9. | YES | SOME | TBD | YES | | |
| 10. | NO | YES | YES | NO | | |
| 11. | YES | YES | YES | YES | | |
| 12. | YES | YES | YES | YES | | |
| 13. | NO | NO | NO | SOME | | |
+-------------+--------+--------+--------+--------+--------+-----+
4. Security Considerations
As an evaluation document, no security considerations are created.
The solution should be safe from route injection to perpetrate man-
in-the-middle attacks, especially in multi-dwelling or other dense/
mesh networks, but this may be a link requirement more than a routing
requirement.
5. IANA Considerations
There are no IANA considerations or implications that arise from this
document.
Howard Expires July 1, 2012 [Page 13]
Internet-Draft Homenet Routing Comparison December 2011
6. Informative References
[OSPFV3-AUTH-TRAILER]
"".
[OSPFv3-autoconfig]
"draft-acee-ospf-ospfv3-autoconfig".
[RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments".
[RFC2080] R. Minnear, "RIPng for IPv6".
[RFC5310] "IS-IS Generic Cryptographic Authentication".
[RPL] "draft-ietf-roll-rpl-19".
[UP-PIO] "draft-howard-up-pio-00".
[draft-howard-homenet-routing-requirements]
"Homenet Routing Requirements", December 2011.
[draft-ietf-homenet-arch]
"Home Networking Architecture for IPv6".
Author's Address
Lee Howard
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1 703 345 3513
Email: lee.howard@twcable.com
Howard Expires July 1, 2012 [Page 14]
