< draft-arkko-homenet-prefix-assignment-00.txt   draft-arkko-homenet-prefix-assignment-01.txt >
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft A. Lindem Internet-Draft A. Lindem
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: April 26, 2012 October 24, 2011 Expires: May 3, 2012 October 31, 2011
Prefix Assignment in a Home Network Prefix Assignment in a Home Network
draft-arkko-homenet-prefix-assignment-00 draft-arkko-homenet-prefix-assignment-01
Abstract Abstract
This memo describes a prefix assignment mechanism for home networks. This memo describes a prefix assignment mechanism for home networks.
It is expected that home gateway routers are assigned an IPv6 prefix It is expected that home gateway routers are assigned an IPv6 prefix
through DHCPv6 Prefix Delegation (PD). This prefix needs to be through DHCPv6 Prefix Delegation (PD). This prefix needs to be
divided among the multiple subnets in a home network. This memo divided among the multiple subnets in a home network. This memo
describes a mechanism for such division via OSPFv3. This is an describes a mechanism for such division via OSPFv3. This is an
alternative design to using DHCPv6 PD also for the prefix assignment. alternative design to using DHCPv6 PD also for the prefix assignment.
The memo is input to the working group so that it can make a decision The memo is input to the working group so that it can make a decision
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 3 3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 3
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
5. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 6 5. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 7
5.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 7 5.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 7
5.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 8 5.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 8
5.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 9 5.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 9
6. Manageability Considerations . . . . . . . . . . . . . . . . . 11 6. Manageability Considerations . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This memo describes a prefix assignment mechanism for home networks. This memo describes a prefix assignment mechanism for home networks.
It is expected that home gateway routers are assigned an IPv6 prefix It is expected that home gateway routers are assigned an IPv6 prefix
through DHCPv6 Prefix Delegation (PD) [RFC3633], or in some cases through DHCPv6 Prefix Delegation (PD) [RFC3633], or in some cases
manually configured. This prefix needs to be divided among the manually configured. This prefix needs to be divided among the
multiple subnets in a home network. This memo describes a mechanism multiple subnets in a home network. This memo describes a mechanism
skipping to change at page 4, line 43 skipping to change at page 4, line 43
connected to another router which in turn is connected to connected to another router which in turn is connected to
hosts, a minimum of two /64 prefixes are required in the hosts, a minimum of two /64 prefixes are required in the
internal network: one between the two routers, and another one internal network: one between the two routers, and another one
for the host-side interface on the second router. But an for the host-side interface on the second router. But an
ineffective assignment mechanism in the two routers might have ineffective assignment mechanism in the two routers might have
both of them asking for an assignment for this shared both of them asking for an assignment for this shared
interface. interface.
o The assignments must be stable across reboots, power cycling, o The assignments must be stable across reboots, power cycling,
router software updates, and preferably, should be stable across router software updates, and preferably, should be stable across
simple network changes such as adding a new device on the stub simple network changes. Simple network changes are in this case
network segments. However, stability across more complex types of defined as those that could be resolved through either deletion or
network reconfiguration events is not a requirement. addition of a prefix assignment. For instance, the addition of a
new router without changing connections between existing routers
requires just the assigment of new prefixes for the new networks
that the router introduces. There are no stability requirements
across more complex types of network reconfiguration events. For
instance, if a network is separated into two networks connected by
a newly inserted router, this may lead into renumbering all
networks within the home.
In an even more complex setting there may be multiple home gateway In an even more complex setting there may be multiple home gateway
routers and multiple connections to ISP(s). These cases are routers and multiple connections to ISP(s). These cases are
analogous to the case of a single gateway router. Each gateway will analogous to the case of a single gateway router. Each gateway will
simply distribute the prefix it has, and participating routers simply distribute the prefix it has, and participating routers
throughout the network may assign themselves prefixes from several throughout the network may assign themselves prefixes from several
gateways. gateways.
Similarly, it is also possible that it is necessary to assign both a Similarly, it is also possible that it is necessary to assign both a
global prefix delegated from the ISP and a local, Unique Local global prefix delegated from the ISP and a local, Unique Local
skipping to change at page 5, line 19 skipping to change at page 5, line 26
applicable to both types of prefixes. For ULA-based prefixes, it is applicable to both types of prefixes. For ULA-based prefixes, it is
necessary to elect one or more router as the generator of such necessary to elect one or more router as the generator of such
prefixes, and have it perform the generation and employ the prefixes prefixes, and have it perform the generation and employ the prefixes
for local interfaces and the entire router network. The generation for local interfaces and the entire router network. The generation
of ULAs in this manner -- and indeed even the question of whether of ULAs in this manner -- and indeed even the question of whether
ULAs are needed -- is outside the scope of this memo, however. We ULAs are needed -- is outside the scope of this memo, however. We
only note that if ULA prefixes are generated, then the mechanisms in only note that if ULA prefixes are generated, then the mechanisms in
this memo can be used to subdivide that prefix for the rest of the this memo can be used to subdivide that prefix for the rest of the
network. network.
Finally, the mechanisms in this memory can also be used in standalone
or ad hoc networks where no global prefixes or Internet connectivity
are available, by distributing ULA prefixes within the network.
4. Router Behavior 4. Router Behavior
This section describes how a router assigns prefixes to its directly This section describes how a router assigns prefixes to its directly
connected interfaces. We assume that the router has prefix(es) that connected interfaces. We assume that the router has prefix(es) that
it can use for this allocation. These prefix(es) can be manually it can use for this allocation. These prefix(es) can be manually
configured, acquired through DHCPv6 PD from the ISP, or learned configured, acquired through DHCPv6 PD from the ISP, or learned
through the distributed prefix assignment protocols described in through the distributed prefix assignment protocols described in
Section 5. Each such prefix is called a usable prefix. Parts of the Section 5. Each such prefix is called a usable prefix. Parts of the
usable prefix may already be assigned for some purpose; a coordinated usable prefix may already be assigned for some purpose; a coordinated
allocation from the prefix is necessary before it can actually be allocation from the prefix is necessary before it can actually be
skipping to change at page 12, line 8 skipping to change at page 12, line 16
This memo makes two allocations out of the OSPFv3 Auto- Configuration This memo makes two allocations out of the OSPFv3 Auto- Configuration
(AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]: (AC) LSA TLV namespace [I-D.acee-ospf-ospfv3-autoconfig]:
o The Usable Prefix TLV in Section 5.1 takes the value TBD-BY-IANA-1 o The Usable Prefix TLV in Section 5.1 takes the value TBD-BY-IANA-1
(suggested value is 2). (suggested value is 2).
o The Assigned Prefix TLV in Section 5.2 takes the value TBD-BY- o The Assigned Prefix TLV in Section 5.2 takes the value TBD-BY-
IANA-2 (suggested value is 3). IANA-2 (suggested value is 3).
9. References 9. Analysis
9.1. Normative References An analysis of a mechanism remiscent of the one described in this
specification has been published in the SIGCOMM IPv6 Workshop
[SIGCOMM.IPV6]. Further analysis is encouraged.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
skipping to change at page 12, line 41 skipping to change at page 13, line 8
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010.
[I-D.acee-ospf-ospfv3-autoconfig] [I-D.acee-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-acee-ospf-ospv3-autoconfig-00 (work in progress), draft-acee-ospf-ospv3-autoconfig-00 (work in progress),
October 2011. October 2011.
9.2. Informative References 10.2. Informative References
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[I-D.chown-homenet-arch] [I-D.chown-homenet-arch]
Arkko, J., Chown, T., Weil, J., and O. Troan, "Home Arkko, J., Chown, T., Weil, J., and O. Troan, "Home
Networking Architecture for IPv6", Networking Architecture for IPv6",
draft-chown-homenet-arch-00 (work in progress), draft-chown-homenet-arch-00 (work in progress),
September 2011. September 2011.
[I-D.chelius-router-autoconf]
Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for
IPv6 router autoconfiguration",
draft-chelius-router-autoconf-00 (work in progress),
June 2002.
[I-D.dimitri-zospf]
Dimitrelis, A. and A. Williams, "Autoconfiguration of
routers using a link state routing protocol",
draft-dimitri-zospf-00 (work in progress), October 2002.
[SIGCOMM.IPV6]
Chelius, G., Fleury, E., Sericola, B., Toutain, L., and D.
Binet, "An evaluation of the NAP protocol for IPv6 router
auto-configuration", ACM SIGCOMM IPv6 Workshop, Kyoto,
Japan, 2007.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank to Tim Chown, Fred Baker, Mark The authors would like to thank to Tim Chown, Fred Baker, Mark
Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Wassim Haddad, Joel Townsley, Lorenzo Colitti, Ole Troan, Ray Bellis, Wassim Haddad, Joel
Halpern, Samita Chakrabarti, Michael Richardson, and Ralph Droms for Halpern, Samita Chakrabarti, Michael Richardson, Anders Brandt, Erik
interesting discussions in this problem space. Nordmark, Laurent Toutain, and Ralph Droms for interesting
discussions in this problem space. The authors would also like to
point out some past work in this space, such as those in
[I-D.chelius-router-autoconf] or [I-D.dimitri-zospf].
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
 End of changes. 12 change blocks. 
16 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/