| < draft-arkko-homenet-prefix-assignment-02.txt | draft-arkko-homenet-prefix-assignment-03.txt > | |||
|---|---|---|---|---|
| Network Working Group J. Arkko | Network Working Group J. Arkko | |||
| Internet-Draft A. Lindem | Internet-Draft A. Lindem | |||
| Intended status: Standards Track Ericsson | Intended status: Standards Track Ericsson | |||
| Expires: January 10, 2013 B. Paterson | Expires: April 26, 2013 B. Paterson | |||
| Cisco Systems | Cisco Systems | |||
| July 9, 2012 | October 23, 2012 | |||
| Prefix Assignment in a Home Network | Prefix Assignment in a Home Network | |||
| draft-arkko-homenet-prefix-assignment-02 | draft-arkko-homenet-prefix-assignment-03 | |||
| 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 allocated an IPv6 prefix | It is expected that home gateway routers are allocated an IPv6 prefix | |||
| through DHCPv6 Prefix Delegation (PD) or that a prefix is made | through DHCPv6 Prefix Delegation (PD) or that a prefix is made | |||
| available through other means. This prefix needs to be divided among | available through other means. This prefix needs to be divided among | |||
| the multiple subnets in a home network. This memo describes a | the multiple subnets in a home network. This memo describes a | |||
| mechanism for such division, or assignment, via OSPFv3. This is an | mechanism for such division, or assignment, via OSPFv3. This is an | |||
| alternative design to also using DHCPv6 PD for the assignment. The | alternative design to also using DHCPv6 PD for the assignment. The | |||
| skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
| 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 January 10, 2013. | This Internet-Draft will expire on April 26, 2013. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 20 ¶ | skipping to change at page 2, line 20 ¶ | |||
| 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 . . . . . . . . . . . . . . . . . . . . 4 | 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 4 | 3. Role of Prefix Assignment . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4.1. Sending Router Advertisements . . . . . . . . . . . . . . 7 | 4.1. Sending Router Advertisements . . . . . . . . . . . . . . 7 | |||
| 4.2. DNS Discovery . . . . . . . . . . . . . . . . . . . . . . 7 | 4.2. DNS Discovery . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5.1. DNS Discovery . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
| 5.2. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 8 | ||||
| 6. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 9 | 6. Prefix Assignment in OSPFv3 . . . . . . . . . . . . . . . . . 9 | |||
| 6.1. Usable Prefix TLV . . . . . . . . . . . . . . . . . . . . 9 | 6.1. Aggregated Prefix TLV . . . . . . . . . . . . . . . . . . 10 | |||
| 6.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 10 | 6.2. Assigned Prefix TLV . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 11 | 6.3. OSPFv3 Prefix Assignment . . . . . . . . . . . . . . . . . 12 | |||
| 6.3.1. Making a New Assignment . . . . . . . . . . . . . . . 14 | 6.3.1. Making a New Assignment . . . . . . . . . . . . . . . 15 | |||
| 6.3.2. Checking for Conflicts Across the Entire Network . . . 15 | 6.3.2. Checking for Conflicts Across the Entire Network . . . 15 | |||
| 6.3.3. Deprecating an Assigned Prefix . . . . . . . . . . . . 15 | 6.3.3. Deprecating an Assigned Prefix . . . . . . . . . . . . 16 | |||
| 6.3.4. Verifying and Making a Local Assignment . . . . . . . 16 | 6.3.4. Verifying and Making a Local Assignment . . . . . . . 16 | |||
| 7. ULA Generation . . . . . . . . . . . . . . . . . . . . . . . . 16 | 7. ULA Generation . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 8. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8. Hysteresis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 9. Manageability Considerations . . . . . . . . . . . . . . . . . 18 | 9. Manageability Considerations . . . . . . . . . . . . . . . . . 19 | |||
| 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
| 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12. Timer Constants . . . . . . . . . . . . . . . . . . . . . . . 19 | 12. Timer Constants . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 | 13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 | 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 | |||
| Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 | Appendix A. Changes in Version -02 . . . . . . . . . . . . . . . 21 | |||
| Appendix B. Changes in Version -03 . . . . . . . . . . . . . . . 21 | ||||
| Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 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 allocated an IPv6 prefix | It is expected that home gateway routers are allocated an IPv6 prefix | |||
| through DHCPv6 Prefix Delegation (PD) [RFC3633], or that a prefix is | through DHCPv6 Prefix Delegation (PD) [RFC3633], or that a prefix is | |||
| made available by some other means. Manual configuration may be | made available by some other means. Manual configuration may be | |||
| needed in some networks, for instance when the ISP does not support | needed in some networks, for instance when the ISP does not support | |||
| DHCPv6-based prefix delegation. In other cases, such as networks | DHCPv6-based prefix delegation. In other cases, such as networks | |||
| skipping to change at page 4, line 26 ¶ | skipping to change at page 4, line 26 ¶ | |||
| internal network interface attached to the router. But it is also | internal network interface attached to the router. But it is also | |||
| common to have two or more internal network interfaces with | common to have two or more internal network interfaces with | |||
| intentionally separate networks. For instance, "private" and "guest" | intentionally separate networks. For instance, "private" and "guest" | |||
| SSIDs are automatically configured in many current home network | SSIDs are automatically configured in many current home network | |||
| routers. When all the network interfaces that require a prefix are | routers. When all the network interfaces that require a prefix are | |||
| attached to the same router, the prefix assignment problem is simple, | attached to the same router, the prefix assignment problem is simple, | |||
| and procedures outlined in Section 4 can be employed. | and procedures outlined in Section 4 can be employed. | |||
| In a more complex setting there are multiple routers in the internal | In a more complex setting there are multiple routers in the internal | |||
| network. There are various possible reasons why this might be | network. There are various possible reasons why this might be | |||
| necessary [I-D.chown-homenet-arch]. For instance, networks that | necessary [I-D.ietf-homenet-arch]. For instance, networks that | |||
| cannot be bridged together should be routed, speed differences | cannot be bridged together should be routed, speed differences | |||
| between wired and wireless interfaces make the use of the same | between wired and wireless interfaces make the use of the same | |||
| broadcast domain undesirable, or simply that router devices keep | broadcast domain undesirable, or simply that router devices keep | |||
| being added. In any case, it then becomes necessary to assign | being added. In any case, it then becomes necessary to assign | |||
| prefixes across the entire network, and this assignment can no longer | prefixes across the entire network, and this assignment can no longer | |||
| be done on a local basis as proposed in Section 4. A distributed | be done on a local basis as proposed in Section 4. A distributed | |||
| mechanism and a protocol are required. | mechanism and a protocol are required. | |||
| The key requirements for this distributed mechanism are as follows. | The key requirements for this distributed mechanism are as follows. | |||
| o A prefix allocated to a home gateway router within the home | o A prefix allocated to a home gateway router within the home | |||
| network is used to assign /64 prefixes on each subnet that | network is used to assign /64 prefixes on each subnet that | |||
| requires one. | requires one. | |||
| Note that several methods may be used to allocate such a usable | Note that several methods may be used to allocate such an | |||
| prefix. | aggregated prefix. | |||
| o The assignment mechanism should provide reasonable efficiency. As | o The assignment mechanism should provide reasonable efficiency. As | |||
| a practical benchmark, some ISPs may employ /60 allocations to | a practical benchmark, some ISPs may employ /60 allocations to | |||
| individual subscribers. As a result, the assignment mechanism | individual subscribers. As a result, the assignment mechanism | |||
| should avoid wasting too many prefixes so that this set of 16 /64 | should avoid wasting too many prefixes so that this set of 16 /64 | |||
| prefixes is not exhausted in the foreseeable future for commonly | prefixes is not exhausted in the foreseeable future for commonly | |||
| occurring network configurations. | occurring network configurations. | |||
| o In particular, the assignment of multiple prefixes to the same | o In particular, the assignment of multiple prefixes to the same | |||
| network from the same top-level prefix must be avoided. | network from the same top-level prefix must be avoided. | |||
| skipping to change at page 6, line 5 ¶ | skipping to change at page 6, line 5 ¶ | |||
| The mechanisms in this memory can also be used in standalone or ad | The mechanisms in this memory can also be used in standalone or ad | |||
| hoc networks where no global prefixes or Internet connectivity are | hoc networks where no global prefixes or Internet connectivity are | |||
| available, by distributing ULA prefixes within the network. | 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 | connected interfaces. We assume that the router has prefix | |||
| allocation(s) that it can use for this assignment. Each such prefix | allocation(s) that it can use for this assignment. Each such prefix | |||
| allocation is called a usable prefix. Parts of the usable prefix may | allocation is called an aggregated prefix. Parts of the aggregated | |||
| already be assigned for some purpose; a coordinated assignment from | prefix may already be assigned for some purpose; a coordinated | |||
| the prefix is necessary before it can actually be assigned to an | assignment from the prefix is necessary before it can actually be | |||
| interface. | assigned to an interface. | |||
| Even if the assignment process is local, it still needs to follow the | Even if the assignment process is local, it still needs to follow the | |||
| requirements from Section 3. This is achieved through the following | requirements from Section 3. This is achieved through the following | |||
| rules: | rules: | |||
| o The router MUST maintain a list of assigned prefixes on a per- | o The router MUST maintain a list of assigned prefixes on a per- | |||
| interface basis. The contents of this list consists of prefixes | interface basis. The contents of this list consists of prefixes | |||
| that the router itself has assigned to the interface, as well as | that the router itself has assigned to the interface, as well as | |||
| prefixes assigned to the interface by other routers. The latter | prefixes assigned to the interface by other routers. The latter | |||
| are learned through the mechanisms described in Section 6, when | are learned through the mechanisms described in Section 6, when | |||
| they are used. Each prefix is associated with the Router ID of | they are used. Each prefix is associated with the Router ID of | |||
| the router that assigned it. | the router that assigned it. | |||
| o Whenever the router finds a combination of an interface and usable | o Whenever the router finds a combination of an interface and | |||
| prefix that is not used on the interface, it SHOULD make a new | aggregated prefix that is not used on the interface, it SHOULD | |||
| prefix assignment. That is, the router checks to see if an | make a new prefix assignment. That is, the router checks to see | |||
| interface and usable prefix exists such that there are no assigned | if an interface and aggregated prefix exists such that there are | |||
| prefixes within that interface that are more specific than the | no assigned prefixes within that interface that are more specific | |||
| usable prefix. In this situation the router makes an allocation | than the aggregated prefix. In this situation the router makes an | |||
| from the usable prefix (if possible) and adds the assignment to | allocation from the aggregated prefix (if possible) and adds the | |||
| the list of assigned prefixes on that interface. | assignment to the list of assigned prefixes on that interface. | |||
| Note: The above implies that when there are multiple usable | Note: The above implies that when there are multiple aggregated | |||
| prefixes, each network will be assigned multiple prefixes. | prefixes, each network will be assigned multiple prefixes. | |||
| o An assignment from a usable prefix MUST be checked against | o An assignment from an aggregated prefix MUST be checked against | |||
| possible other assignments from the same usable prefix on the same | possible other assignments from the same aggregated prefix on the | |||
| link by neighboring routers, to avoid unnecessary assignments. | same link by neighboring routers, to avoid unnecessary | |||
| Assignments MUST also be examined against all existing assignments | assignments. Assignments MUST also be examined against all | |||
| from the same usable prefix across the network, to avoid | existing assignments from the same aggregated prefix across the | |||
| collisions. Assignments are made for individual /64 prefixes. | network, to avoid collisions. Assignments are made for individual | |||
| The choice of a /64 prefix among multiple free ones MUST be made | /64 prefixes. The choice of a /64 prefix among multiple free ones | |||
| randomly or based on an algorithm that takes unique hardware | MUST be made randomly or based on an algorithm that takes unique | |||
| characteristics of the router and the interface into account. | hardware characteristics of the router and the interface into | |||
| This helps avoid collisions when simultaneous assignments are made | account. This helps avoid collisions when simultaneous | |||
| within a network. | assignments are made within a network. | |||
| o In order to provide a stable assignment, the router MUST store | o In order to provide a stable assignment, the router MUST store | |||
| assignments affecting directly connected interfaces and | assignments affecting directly connected interfaces and | |||
| automatically generated ULA prefixes in non-volatile memory and | automatically generated ULA prefixes in non-volatile memory and | |||
| attempt to re-use them in the future when possible. At least the | attempt to re-use them in the future when possible. At least the | |||
| 5 most recent assignments SHOULD be stored. Note that this | 5 most recent assignments SHOULD be stored. Note that this | |||
| applies to both its own assignments as well as assignments made by | applies to both its own assignments as well as assignments made by | |||
| others. This ensures that the same prefix assignments are made | others. This ensures that the same prefix assignments are made | |||
| regardless of the order that different devices are brought up. To | regardless of the order that different devices are brought up. To | |||
| avoid attacks on flash memory write cycles, assignments made by | avoid attacks on flash memory write cycles, assignments made by | |||
| others SHOULD be recorded only after 10 minutes have passed and | others SHOULD be recorded only after 10 minutes have passed and | |||
| the assignment is still valid. | the assignment is still valid. | |||
| o Re-using a memorized assignment is possible when a usable prefix | o Re-using a memorized assignment is possible when a aggregated | |||
| exists that is less specific than the prefix in the assignment (or | prefix exists that is less specific than the prefix in the | |||
| it is the prefix itself in the assignment), and the prefix is | assignment (or it is the prefix itself in the assignment), and the | |||
| currently unassigned. | prefix is currently unassigned. | |||
| 4.1. Sending Router Advertisements | 4.1. Sending Router Advertisements | |||
| Once the router has assigned a prefix to an interface, it MUST act as | Once the router has assigned a prefix to an interface, it MUST act as | |||
| a router as defined in [RFC4861] and advertise the prefix in Router | a router as defined in [RFC4861] and advertise the prefix in Router | |||
| Advertisements. The lifetime of the prefix SHOULD be advertised as a | Advertisements. The lifetime of the prefix SHOULD be advertised as a | |||
| reasonably long period, at least 48 hours or the lifetime of the | reasonably long period, at least 48 hours or the lifetime of the | |||
| assigned prefixes, whichever is smaller. | assigned prefixes, whichever is smaller. | |||
| 4.2. DNS Discovery | 4.2. DNS Discovery | |||
| To support a variety of IPv6-only hosts in these networks, the router | To support a variety of IPv6-only hosts in these networks, the router | |||
| needs to ensure that sufficient DNS discovery mechanisms are enabled. | needs to ensure that sufficient DNS discovery mechanisms are enabled. | |||
| It is RECOMMENDED that both stateless DHCPv6 [RFC3736] and Router | It is RECOMMENDED that both stateless DHCPv6 [RFC3736] and Router | |||
| Advertisement options [RFC6106] are supported and turned on by | Advertisement options [RFC6106] are supported and turned on by | |||
| default. | default in routers. | |||
| The above requires, however, that a working DNS server is known and | The above requires, however, that a working DNS server is known and | |||
| addressable via IPv6. The mechanism in [RFC3736] and [RFC3646] can | addressable via IPv6. The mechanism in [RFC3736] and [RFC3646] can | |||
| be used for this. It is RECOMMENDED that each router attempts to | be used for this. It is RECOMMENDED that each router attempts to | |||
| discover an existing DNS server. Typically, such a server will be | discover an existing DNS server. Typically, such a server will be | |||
| provided by an ISP. However, in some cases no such server can be | provided by an ISP. However, in some cases no such server can be | |||
| found. For instance, an ISP may provide only IPv4 DNS server | found. For instance, an ISP may provide only IPv4 DNS server | |||
| addresses, or a router deep within the home network is unaware of the | addresses, or a router deep within the home network is unaware of the | |||
| IPv6 DNS servers that a home gateway router has discovered. In these | IPv6 DNS servers that a home gateway router has discovered. In these | |||
| situations it is RECOMMENDED that each router turns on a local DNS | situations it is RECOMMENDED that each router turns on a local DNS | |||
| relay that fetches information from the IPv4 Internet (if a working | relay that fetches information from the IPv4 Internet (if a working | |||
| IPv4 DNS server is available) or a full DNS server that fetches | IPv4 DNS server is available) or a full DNS server that fetches | |||
| information from the DNS root. | information from the DNS root. | |||
| As a result of these recommendations, as long as there is | ||||
| reachability to at least the Internet, every router within the home | ||||
| network will either know the IPv6 address of a DNS server or it | ||||
| itself runs a server that can fetch information from the Internet. | ||||
| As a result, the router can provide information about the server | ||||
| address to hosts in directly connected networks. | ||||
| 5. Design Choices | 5. Design Choices | |||
| 5.1. DNS Discovery | ||||
| The DNS discovery recommendations in Section 4.2 ensure that an IPv6- | The DNS discovery recommendations in Section 4.2 ensure that an IPv6- | |||
| only home network can resolve names. However, these recommendations | only home network can resolve names. However, these recommendations | |||
| are suboptimal in the sense that different routers in the home may | are suboptimal in the sense that different routers in the home may | |||
| provide different DNS servers, or multiple local DNS servers have to | provide different DNS servers, or multiple local DNS servers have to | |||
| be run where it would have been possible to point to one, or even | be run where it would have been possible to point to one, or even | |||
| point to the one provided by the ISP. However, better coordination | point to the one provided by the ISP. However, better coordination | |||
| for the DNS server selection would require some form of additional | for the DNS server selection would require some form of additional | |||
| communication between the routers in the home network. The authors | communication between the routers in the home network. The authors | |||
| solicit opinions from the Working Group on whether this is something | solicit opinions from the Working Group on whether this is something | |||
| that should be specified. | that should be specified. However, the current design is easy to | |||
| deploy even when not all routers within the network support Homenet | ||||
| specifications yet; the mechanism provides an incremental improvement | ||||
| to IPv6 DNS reachability even when the first Homenet router is | ||||
| deployed. | ||||
| 5.2. Prefix Assignment | ||||
| The OSPFv3-based prefix assignment protocol needs to detect two types | The OSPFv3-based prefix assignment protocol needs to detect two types | |||
| of conflicts: | of conflicts: | |||
| 1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for | 1. Two or more OSPFv3 routers have assigned the same IPv6 prefix for | |||
| different networks. | different networks. | |||
| 2. Two or more OSPFv3 routers have assigned different IPv6 prefixes | 2. Two or more OSPFv3 routers have assigned different IPv6 prefixes | |||
| for the same network. | for the same network. | |||
| skipping to change at page 9, line 12 ¶ | skipping to change at page 9, line 27 ¶ | |||
| Interface IDs that they advertise in these TLVs. The OSPFv3 | Interface IDs that they advertise in these TLVs. The OSPFv3 | |||
| Router with a numerically lower OSPFv3 Router ID should accept | Router with a numerically lower OSPFv3 Router ID should accept | |||
| the global IPv6 prefix from the neighbor with the highest OSPFv3 | the global IPv6 prefix from the neighbor with the highest OSPFv3 | |||
| Router ID. | Router ID. | |||
| 6. Prefix Assignment in OSPFv3 | 6. Prefix Assignment in OSPFv3 | |||
| This section describes how prefix assignment in a home network can be | This section describes how prefix assignment in a home network can be | |||
| performed in a distributed manner via OSPFv3. It is expected that | performed in a distributed manner via OSPFv3. It is expected that | |||
| the router already support the auto-configuration extensions defined | the router already support the auto-configuration extensions defined | |||
| in [I-D.acee-ospf-ospfv3-autoconfig]. | in [I-D.ietf-ospf-ospfv3-autoconfig]. | |||
| An overview of OSPFv3-based prefix assignment is as follows. OSPFv3 | An overview of OSPFv3-based prefix assignment is as follows. OSPFv3 | |||
| routers that are capable of auto-configuration advertise an OSPFv3 | routers that are capable of auto-configuration advertise an OSPFv3 | |||
| Auto-Configuration (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig] with | Auto-Configuration (AC) LSA [I-D.ietf-ospf-ospfv3-autoconfig] with | |||
| suitable TLVs. For prefix assignment, two TLVs are used. The Usable | suitable TLVs. For prefix assignment, two TLVs are used. The | |||
| Prefix TLV (Section 6.1) advertises a usable prefix, usually the | Aggregated Prefix TLV (Section 6.1) advertises an aggregated prefix, | |||
| prefix that has been delegated to the home gateway router from the | usually the prefix that has been delegated to the home gateway router | |||
| ISP through DHCPv6 PD. These usable prefixes are necessary for | from the ISP through DHCPv6 PD. These aggregated prefixes are | |||
| running the algorithm in Section 4 for determining whether prefix | necessary for running the algorithm in Section 4 for determining | |||
| assignments can and should be made. | whether prefix assignments can and should be made. | |||
| The Assigned Prefix TLV (Section 6.2) is used to communicate | The Assigned Prefix TLV (Section 6.2) is used to communicate | |||
| assignments that routers make out of the usable prefixes. | assignments that routers make out of the aggregated prefixes. | |||
| An assignment can be made when the algorithm in Section 4 indicates | An assignment can be made when the algorithm in Section 4 indicates | |||
| that it can be made and no other router has claimed the same | that it can be made and no other router has claimed the same | |||
| assignment. The router makes an OSPFv3 advertisement with the | assignment. The router makes an OSPFv3 advertisement with the | |||
| Assigned Prefix TLV included to let other devices know that the | Assigned Prefix TLV included to let other devices know that the | |||
| prefix is now in use. Unfortunately, collisions are still possible, | prefix is now in use. Unfortunately, collisions are still possible, | |||
| when the algorithms on different routers happen to choose the same | when the algorithms on different routers happen to choose the same | |||
| free /64 prefix or when more /64 prefixes are needed than are | free /64 prefix or when more /64 prefixes are needed than are | |||
| available. This situation is detected through an advertisement where | available. This situation is detected through an advertisement where | |||
| a different router claims the assignment of the same prefix. In this | a different router claims the assignment of the same prefix. In this | |||
| situation the router with the numerically lower OSPFv3 Router ID has | situation the router with the numerically lower OSPFv3 Router ID has | |||
| to select another prefix and immediately withdraw any assignments and | to select another prefix and immediately withdraw any assignments and | |||
| advertisements that may have been advertised in OSPFv3. See also | advertisements that may have been advertised in OSPFv3. See also | |||
| Section 5.2 in [I-D.acee-ospf-ospfv3-autoconfig]. | Section 5.2 in [I-D.ietf-ospf-ospfv3-autoconfig]. | |||
| 6.1. Usable Prefix TLV | 6.1. Aggregated Prefix TLV | |||
| The Usable Prefix TLV is defined for the OSPFv3 Auto-Configuration | The Aggregated Prefix TLV is defined for the OSPFv3 Auto- | |||
| (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- | Configuration (AC) LSA [I-D.ietf-ospf-ospfv3-autoconfig]. It will | |||
| BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC LSA with an | have type TBD-BY-IANA-1 and MUST be advertised in the LSID OSPFv3 AC | |||
| LSID of 0. It MAY occur once or multiple times and the information | LSA with an LSID of 0. It MAY occur once or multiple times and the | |||
| from all TLV instances is retained. The length of the TLV is | information from all TLV instances is retained. The length of the | |||
| variable. | TLV is variable. | |||
| The contents of the TLV include a usable prefix (Prefix) and prefix | The contents of the TLV include an aggregated prefix (Prefix) and | |||
| length (PrefixLength). PrefixLength is the length in bits of the | prefix length (PrefixLength). PrefixLength is the length in bits of | |||
| prefix and is an 8-bit field. The PrefixLength MUST be greater than | the prefix and is an 8-bit field. The PrefixLength MUST be greater | |||
| or equal to 8 and less than or equal to 64. The prefix describes an | than or equal to 8 and less than or equal to 64. The prefix | |||
| allocation of a global or ULA prefix for the entire auto-configured | describes an allocation of a global or ULA prefix for the entire | |||
| home network. The Prefix is an encoding of the prefix itself as an | auto-configured home network. The Prefix is an encoding of the | |||
| even multiple of 32-bit words, padding with zero bits as necessary. | prefix itself as an even multiple of 32-bit words, padding with zero | |||
| This encoding consumes (PrefixLength + 31) / 32) 32-bit words and is | bits as necessary. This encoding consumes (PrefixLength + 31) / 32) | |||
| consistent with [RFC5340]. It MUST NOT be directly assigned to any | 32-bit words and is consistent with [RFC5340]. It MUST NOT be | |||
| interface before following the procedures defined in this memo. | directly assigned to any interface before following the procedures | |||
| defined in this memo. | ||||
| This TLV SHOULD be advertised by every home gateway router that has | This TLV SHOULD be advertised by every home gateway router that has | |||
| either a manual, DHCPv6 PD-based, or generated ULA prefix that is | either a manual, DHCPv6 PD-based, or generated ULA prefix that is | |||
| shorter than /64. | shorter than /64. | |||
| This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, | This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, | |||
| and only in combination with the Router-Hardware-Fingerprint TLV | and only in combination with the Router-Hardware-Fingerprint TLV | |||
| [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. | [I-D.ietf-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | TBD-BY-IANA-1 | Length | | | TBD-BY-IANA-1 | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | PrefixLength | Reserved | | | PrefixLength | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | | |||
| | Prefix | | | Prefix | | |||
| | (4-16 bytes) | | | (4-16 bytes) | | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Usable Prefix TLV Format | Aggregated Prefix TLV Format | |||
| 6.2. Assigned Prefix TLV | 6.2. Assigned Prefix TLV | |||
| The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration | The Assigned Prefix TLV is defined for the OSPFv3 Auto-Configuration | |||
| (AC) LSA [I-D.acee-ospf-ospfv3-autoconfig]. It will have type TBD- | (AC) LSA [I-D.ietf-ospf-ospfv3-autoconfig]. It will have type TBD- | |||
| BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an | BY-IANA-2 and MUST be advertised in the LSID OSPFv3 AC LSA with an | |||
| LSID of 0. It MAY occur once or multiple times and the information | LSID of 0. It MAY occur once or multiple times and the information | |||
| from all TLV instances is retained. The length of the TLV is | from all TLV instances is retained. The length of the TLV is | |||
| variable. | variable. | |||
| The contents of the TLV include an Interface ID, assigned prefix | The contents of the TLV include an Interface ID, assigned prefix | |||
| (Prefix), and prefix length (PrefixLength). The Interface ID is the | (Prefix), and prefix length (PrefixLength). The Interface ID is the | |||
| same OSPFv3 Interface ID that is described in section 4.2.1 or | same OSPFv3 Interface ID that is described in section 4.2.1 or | |||
| [RFC5340]. PrefixLength is the length in bits of the prefix and is | [RFC5340]. PrefixLength is the length in bits of the prefix and is | |||
| an 8-bit field. The PrefixLength value MUST be 64 in this version of | an 8-bit field. The PrefixLength value MUST be 64 in this version of | |||
| the specification. The prefix describes an assignment of a global or | the specification. The prefix describes an assignment of a global or | |||
| ULA prefix for a directly connected interface in the advertising | ULA prefix for a directly connected interface in the advertising | |||
| router. The Prefix is an encoding of the prefix itself as an even | router. The Prefix is an encoding of the prefix itself as an even | |||
| multiple of 32-bit words, padding with zero bits as necessary. This | multiple of 32-bit words, padding with zero bits as necessary. This | |||
| encoding consumes (PrefixLength + 31) / 32) 32-bit words and is | encoding consumes (PrefixLength + 31) / 32) 32-bit words and is | |||
| consistent with [RFC5340]. | consistent with [RFC5340]. | |||
| This TLV MUST be advertised by the router that has made assignment | This TLV MUST be advertised by the router that has made assignment | |||
| from a usable prefix per Section 4. | from an aggregated prefix per Section 4. | |||
| This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, | This TLV MUST appear inside an OSPFv3 Router Auto-Configuration LSA, | |||
| and only in combination with the Router-Hardware-Fingerprint TLV | and only in combination with the Router-Hardware-Fingerprint TLV | |||
| [I-D.acee-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. | [I-D.ietf-ospf-ospfv3-autoconfig] Section 5.2.2 in the same LSA. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | TBD-BY-IANA-2 | Length | | | TBD-BY-IANA-2 | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Interface ID | | | Interface ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | PrefixLength | Reserved | | | PrefixLength | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 11, line 38 ¶ | skipping to change at page 12, line 10 ¶ | |||
| | | | | | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Assigned Prefix TLV Format | Assigned Prefix TLV Format | |||
| 6.3. OSPFv3 Prefix Assignment | 6.3. OSPFv3 Prefix Assignment | |||
| OSPFv3 Routers supporting the mechanisms in the memo will learn or | OSPFv3 Routers supporting the mechanisms in the memo will learn or | |||
| assign a global /64 IPv6 prefix for each IPv6 interface. Since the | assign a global /64 IPv6 prefix for each IPv6 interface. Since the | |||
| mechanisms described herein are based on OSPFv3, Router ID assignment | mechanisms described herein are based on OSPFv3, Router ID assignment | |||
| as described in [I-D.acee-ospf-ospfv3-autoconfig] MUST have completed | as described in [I-D.ietf-ospf-ospfv3-autoconfig] MUST have completed | |||
| successfully. | successfully. | |||
| When an OSPFv3 Router receives a global prefix through DHCPv6 prefix | When an OSPFv3 Router receives a global prefix through DHCPv6 prefix | |||
| delegation, manual configuration, or other means, it SHOULD advertise | delegation, manual configuration, or other means, it SHOULD advertise | |||
| this prefix by including the Usable Prefix TLV in its OSPFv3 AC LSA. | this prefix by including the Aggregated Prefix TLV in its OSPFv3 AC | |||
| This will trigger prefix assignment for auto-configured OSPFv3 | LSA. This will trigger prefix assignment for auto-configured OSPFv3 | |||
| routers within the routing domain including the originating OSPFv3 | routers within the routing domain including the originating OSPFv3 | |||
| router. | router. | |||
| Discussion: Note that while having multiple routers advertise the | Discussion: Note that while having multiple routers advertise the | |||
| same usable address space (or address space that covers another | same aggregated address space (or address space that covers | |||
| router's usable address space) is a configuration error, it should | another router's aggregated address space) is a configuration | |||
| not result in any adverse effects, as long as assignments from | error, it should not result in any adverse effects, as long as | |||
| such space are still checked for collisions against all other | assignments from such space are still checked for collisions | |||
| assignments from the same address space. | against all other assignments from the same address space. | |||
| When an OSPFv3 Router detects a change in the set of AC LSAs in its | When an OSPFv3 Router detects a change in the set of AC LSAs in its | |||
| LSA database, it will run the prefix assignment algorithm. The | LSA database, it will run the prefix assignment algorithm. The | |||
| purpose of this algorithm is to determine, for each Usable Prefix in | purpose of this algorithm is to determine, for each Aggregated Prefix | |||
| the database, whether or not a new prefix needs to be assigned for | in the database, whether or not a new prefix needs to be assigned for | |||
| each of its attached IPv6 interfaces and whether or not existing | each of its attached IPv6 interfaces and whether or not existing | |||
| assignments need to be deprecated. The algorithm also detects and | assignments need to be deprecated. The algorithm also detects and | |||
| removes assignments for which there is no longer a corresponding | removes assignments for which there is no longer a corresponding | |||
| Usable Prefix. Before the algorithm is run, all existing assignments | Aggregated Prefix. Before the algorithm is run, all existing | |||
| in assigned prefix lists for directly connected interfaces must be | assignments in assigned prefix lists for directly connected | |||
| marked as "invalid" and will be deleted at the end of the algorithm | interfaces must be marked as "invalid" and will be deleted at the end | |||
| if they are still in this state. An assigned prefix is considered to | of the algorithm if they are still in this state. An assigned prefix | |||
| be "valid" if all the following conditions are met: | is considered to be "valid" if all the following conditions are met: | |||
| o A containing Usable Prefix TLV exists in reachable AC LSA(s). | o A containing Aggregated Prefix TLV exists in reachable AC LSA(s). | |||
| o An Assigned Prefix TLV that matches this assignment exactly (same | o An Assigned Prefix TLV that matches this assignment exactly (same | |||
| prefix, same router and interface ID associated with the | prefix, same router and interface ID associated with the | |||
| assignment) exist in reachable AC LSA(s). | assignment) exist in reachable AC LSA(s). | |||
| o Any router advertising an assignment for the same link and Usable | o Any router advertising an assignment for the same link and | |||
| Prefix has a lower Router ID than the source of this assignment. | Aggregated Prefix has a lower Router ID than the source of this | |||
| assignment. | ||||
| o If this router is the source of the assignment, any router in the | o If this router is the source of the assignment, any router in the | |||
| network that has assigned the same prefix on a different link has | network that has assigned the same prefix on a different link has | |||
| a lower Router ID than this router. | a lower Router ID than this router. | |||
| Note that this definition of a "valid assignment" depends on the | Note that this definition of a "valid assignment" depends on the | |||
| router running the algorithm: in particular, a router is not expected | router running the algorithm: in particular, a router is not expected | |||
| to detect prefix collisions or duplicate prefix assignments that do | to detect prefix collisions or duplicate prefix assignments that do | |||
| not concern assignments for which it is the responsible router. It | not concern assignments for which it is the responsible router. It | |||
| is the role of the responsible router to detect these cases and | is the role of the responsible router to detect these cases and | |||
| update its AC LSAs accordingly. A router is, however, expected to | update its AC LSAs accordingly. A router is, however, expected to | |||
| react to these updates from other routers which translate into | react to these updates from other routers which translate into | |||
| additions or removals of Usable Prefix or Assigned Prefix TLVs. | additions or removals of Aggregated Prefix or Assigned Prefix TLVs. | |||
| The router is expected to have made a snapshot of the LSA database | The router is expected to have made a snapshot of the LSA database | |||
| before running this algorithm. The prefix assignment algorithm | before running this algorithm. The prefix assignment algorithm | |||
| consists of the following steps run once per combination of Usable | consists of the following steps run once per combination of | |||
| Prefix in the LSA database and directly connected OSPFv3 interface. | Aggregated Prefix in the LSA database and directly connected OSPFv3 | |||
| For the purposes of this discussion, the Usable Prefix will be | interface. For the purposes of this discussion, the Aggregated | |||
| referred to as the Current Usable Prefix, and the interface will be | Prefix will be referred to as the Current Aggregated Prefix, and the | |||
| referred to as the Current Interface. The following steps will be | interface will be referred to as the Current Interface. The | |||
| performed for each tuple (Usable Prefix, OSPFv3 interface): | following steps will be performed for each tuple (Aggregated Prefix, | |||
| OSPFv3 interface): | ||||
| 1. The OSPFv3 Router will search all AC LSAs for a Usable Prefix TLV | 1. The OSPFv3 Router will search all AC LSAs for an Aggregated | |||
| describing a prefix which contains but is not equal to the | Prefix TLV describing a prefix which contains but is not equal to | |||
| Current Usable Prefix. If such a prefix is found, the algorithm | the Current Aggregated Prefix. If such a prefix is found, the | |||
| is skipped for the Current Usable Prefix as it either has or will | algorithm is skipped for the Current Aggregated Prefix as it | |||
| be run for the shorter prefix. | either has or will be run for the shorter prefix. | |||
| 2. The OSPFv3 router will examine its list of neighbors to find all | 2. The OSPFv3 router will examine its list of neighbors to find all | |||
| neighbors in state greater than Init (these neighbors will be | neighbors in state greater than Init (these neighbors will be | |||
| referred to as active neighbors). | referred to as active neighbors). | |||
| 3. The following three steps will serve to determine whether an | 3. The following three steps will serve to determine whether an | |||
| assignment needs to be made on the link: | assignment needs to be made on the link: | |||
| i. | i. | |||
| skipping to change at page 13, line 31 ¶ | skipping to change at page 13, line 50 ¶ | |||
| highest Router ID of all active OSPFv3 routers on the link. | highest Router ID of all active OSPFv3 routers on the link. | |||
| ii. | ii. | |||
| If OSPFv3 active neighbors are present on the link, the router | If OSPFv3 active neighbors are present on the link, the router | |||
| will determine whether any of them have already assigned an | will determine whether any of them have already assigned an | |||
| IPv6 prefix. This is done by examining the AC LSAs of all the | IPv6 prefix. This is done by examining the AC LSAs of all the | |||
| active neighbors on the link and looking for any that include | active neighbors on the link and looking for any that include | |||
| an Assigned Prefix TLV with the same OSPFv3 Router ID and | an Assigned Prefix TLV with the same OSPFv3 Router ID and | |||
| Interface ID as the neighbor has. If one is found and it is a | Interface ID as the neighbor has. If one is found and it is a | |||
| subnet of the IPv6 prefix advertised in the Usable Prefix TLV, | subnet of the IPv6 prefix advertised in the Aggregated Prefix | |||
| the router stores this prefix and the Router ID of the router | TLV, the router stores this prefix and the Router ID of the | |||
| advertising it for reference in the next step. If several | router advertising it for reference in the next step. If | |||
| such prefixes are found, only the prefix and Router ID with | several such prefixes are found, only the prefix and Router ID | |||
| the numerically highest Router ID are stored. | with the numerically highest Router ID are stored. | |||
| iii. | iii. | |||
| The router will compare its Router ID with the highest Router | The router will compare its Router ID with the highest Router | |||
| ID among neighbors which have made an assignment on the link. | ID among neighbors which have made an assignment on the link. | |||
| If it is higher (or if no assignments have been made by any | If it is higher (or if no assignments have been made by any | |||
| neighbors), it will determine whether or not it is already the | neighbors), it will determine whether or not it is already the | |||
| source of an assignment for the Current Interface from the | source of an assignment for the Current Interface from the | |||
| Current Usable Prefix. | Current Aggregated Prefix. | |||
| 4. There are four possibilities at this stage: | 4. There are four possibilities at this stage: | |||
| * The router has already made an assignment on the link and has | * The router has already made an assignment on the link and has | |||
| a higher Router ID than all eventual neighbors which have also | a higher Router ID than all eventual neighbors which have also | |||
| made an assignment. In this case, the router's existing | made an assignment. In this case, the router's existing | |||
| assignment takes precedence over all other eventual existing | assignment takes precedence over all other eventual existing | |||
| assignments on the link, but the router must determine whether | assignments on the link, but the router must determine whether | |||
| its assignment is still valid throughout the whole network. | its assignment is still valid throughout the whole network. | |||
| This is described in Section 6.3.2. | This is described in Section 6.3.2. | |||
| skipping to change at page 14, line 19 ¶ | skipping to change at page 14, line 38 ¶ | |||
| lower Router ID than the neighbor. In this case, the | lower Router ID than the neighbor. In this case, the | |||
| neighbor's assignment takes precedence over all eventual | neighbor's assignment takes precedence over all eventual | |||
| existing assignments on the link (including assignments made | existing assignments on the link (including assignments made | |||
| by the router), and the router must update the assigned prefix | by the router), and the router must update the assigned prefix | |||
| list of the Current Interface as well as check assignments on | list of the Current Interface as well as check assignments on | |||
| other interfaces for potential collisions. This is described | other interfaces for potential collisions. This is described | |||
| in Section 6.3.4. | in Section 6.3.4. | |||
| * No assignment has been made by anyone on the link, and the | * No assignment has been made by anyone on the link, and the | |||
| router has the highest Router ID on the link. In this case, | router has the highest Router ID on the link. In this case, | |||
| it must make an assignment from the Current Usable Prefix. | it must make an assignment from the Current Aggregated Prefix. | |||
| This is described in Section 6.3.1. | This is described in Section 6.3.1. | |||
| * No assignment has been made by anyone on the link, and the | * No assignment has been made by anyone on the link, and the | |||
| router does not have the highest Router ID on the link. In | router does not have the highest Router ID on the link. In | |||
| this case, the algorithm exits as the router is not | this case, the algorithm exits as the router is not | |||
| responsible for prefix assignment on the link. | responsible for prefix assignment on the link. | |||
| Once the algorithm has been run for each Usable Prefix and each | Once the algorithm has been run for each Aggregated Prefix and each | |||
| interface, the router must delete all assignments that are not marked | interface, the router must delete all assignments that are not marked | |||
| as valid on all assigned prefix lists and deprecate the corresponding | as valid on all assigned prefix lists and deprecate the corresponding | |||
| addresses. If this leads to deleting an assignment that this router | addresses. If this leads to deleting an assignment that this router | |||
| was responsible for, or if AC LSA origination was scheduled during | was responsible for, or if AC LSA origination was scheduled during | |||
| the algorithm, it must originate a new AC LSA advertising the | the algorithm, it must originate a new AC LSA advertising the | |||
| changes. The router MUST also deprecate deleted prefixes as | changes. The router MUST also deprecate deleted prefixes as | |||
| specified in Section 6.3.3. | specified in Section 6.3.3. | |||
| 6.3.1. Making a New Assignment | 6.3.1. Making a New Assignment | |||
| This procedure is executed when no assignment exists on the link and | This procedure is executed when no assignment exists on the link and | |||
| the router is responsible for making an assignment. The router MUST: | the router is responsible for making an assignment. The router MUST: | |||
| 1. Examine all the AC LSAs not advertised by this router that | 1. Examine all the AC LSAs not advertised by this router that | |||
| include Assigned Prefix TLVs that are subnets of the Current | include Assigned Prefix TLVs that are subnets of the Current | |||
| Usable Prefix, as well as all assignments made by this router, to | Aggregated Prefix, as well as all assignments made by this | |||
| determine which prefixes are already assigned. | router, to determine which prefixes are already assigned. | |||
| 2. Examine former prefix assignments stored in non-volatile storage | 2. Examine former prefix assignments stored in non-volatile storage | |||
| for the interface. Starting with the most recent assignment, if | for the interface. Starting with the most recent assignment, if | |||
| the prefix is both a subnet of the Current Usable Prefix and is | the prefix is both a subnet of the Current Aggregated Prefix and | |||
| currently unassigned, reuse the assignment for the interface. | is currently unassigned, reuse the assignment for the interface. | |||
| 3. If no unused former prefix assignment is found, and an unassigned | 3. If no unused former prefix assignment is found, and an unassigned | |||
| /64 subnet of the Current Usable Prefix exists, assign that | /64 subnet of the Current Aggregated Prefix exists, assign that | |||
| prefix to the interface. | prefix to the interface. | |||
| 4. If no OSPFv3 neighbors have been discovered and previous prefix | 4. If no OSPFv3 neighbors have been discovered and previous prefix | |||
| assignments exist, the router can make the assignments | assignments exist, the router can make the assignments | |||
| immediately. Otherwise, the hysteresis periods specified in | immediately. Otherwise, the hysteresis periods specified in | |||
| Section 8 are applied before making an assignment. | Section 8 are applied before making an assignment. | |||
| 5. In the event that no assignment could be made to the interface, a | 5. In the event that no assignment could be made to the interface, a | |||
| warning must be raised. However, the router MUST remain in a | warning must be raised. However, the router MUST remain in a | |||
| state where it continues to assign prefixes through OSPFv3, as | state where it continues to assign prefixes through OSPFv3, as | |||
| prefixes may later become available. | prefixes may later become available. | |||
| 6. Once a global IPv6 prefix is assigned, the router will mark it as | 6. Once a global IPv6 prefix is assigned, the router will mark it as | |||
| valid and schedule re-origination of the AC LSA including the | valid and schedule re-origination of the AC LSA including the | |||
| Assigned Prefix TLV once all Usable Prefixes and interfaces have | Assigned Prefix TLV once all Aggregated Prefixes and interfaces | |||
| been examined. | have been examined. | |||
| 6.3.2. Checking for Conflicts Across the Entire Network | 6.3.2. Checking for Conflicts Across the Entire Network | |||
| This procedure is executed for every assignment that the router | This procedure is executed for every assignment that the router | |||
| intends to make or retain as the router responsible for an | intends to make or retain as the router responsible for an | |||
| assignment. | assignment. | |||
| The router MUST verify that this assignment is still valid across the | The router MUST verify that this assignment is still valid across the | |||
| whole network. This assigned prefix will be referred to as the | whole network. This assigned prefix will be referred to as the | |||
| Current Assigned Prefix. The router will search for a reachable AC | Current Assigned Prefix. The router will search for a reachable AC | |||
| skipping to change at page 16, line 46 ¶ | skipping to change at page 17, line 17 ¶ | |||
| used for that as well. | used for that as well. | |||
| When an OSPFv3 Router detects a change in the set of AC LSAs in its | When an OSPFv3 Router detects a change in the set of AC LSAs in its | |||
| LSA database, it will run the ULA generation algorithm. The purpose | LSA database, it will run the ULA generation algorithm. The purpose | |||
| of this algorithm is to determine whether a new ULA prefix needs to | of this algorithm is to determine whether a new ULA prefix needs to | |||
| be generated. There is no need for this router to generate a new ULA | be generated. There is no need for this router to generate a new ULA | |||
| prefix when any of the following conditions are met: | prefix when any of the following conditions are met: | |||
| i. | i. | |||
| A Usable Prefix TLV exists in an AC LSA advertised by a reachable | An Aggregated Prefix TLV exists in an AC LSA advertised by a | |||
| router in the LSA database, with either global or ULA address | reachable router in the LSA database, with either global or ULA | |||
| space. | address space. | |||
| ii. | ii. | |||
| A reachable router in the OSPFv3 topology with a higher Router ID | A reachable router in the OSPFv3 topology with a higher Router ID | |||
| than this OSPFv3 router exists. | than this OSPFv3 router exists. | |||
| iii. | iii. | |||
| This router has assignments from either IPv4 or IPv6 global | This router has assignments from either IPv4 or IPv6 global | |||
| address space on any interface, or there is connectivity to the | address space on any interface, or there is connectivity to the | |||
| skipping to change at page 17, line 48 ¶ | skipping to change at page 18, line 18 ¶ | |||
| If the router has made such an allocation, it SHOULD continue to | If the router has made such an allocation, it SHOULD continue to | |||
| advertise the prefix in OSPFv3 for as long as conditions i) through | advertise the prefix in OSPFv3 for as long as conditions i) through | |||
| iii) do not apply, with the exception of the generated ULA prefix | iii) do not apply, with the exception of the generated ULA prefix | |||
| that this router is advertising. | that this router is advertising. | |||
| If the router has made such an allocation, and any of the conditions | If the router has made such an allocation, and any of the conditions | |||
| become true (except for the case of the ULA prefix that the router is | become true (except for the case of the ULA prefix that the router is | |||
| advertising) even after applying the hysteresis principles from | advertising) even after applying the hysteresis principles from | |||
| Section 8, then the OSPFv3 router SHOULD withdraw the advertisement | Section 8, then the OSPFv3 router SHOULD withdraw the advertisement | |||
| for the usable prefix. This is done by scheduling the re-origination | for the aggregated prefix. This is done by scheduling the re- | |||
| of an AC LSA that does not include the Usable Prefix TLV with the | origination of an AC LSA that does not include the Aggregated Prefix | |||
| ULA. Note that as a result of the general algorithm for making | TLV with the ULA. Note that as a result of the general algorithm for | |||
| prefix assignments, any /64 prefix assignments from the ULA prefix | making prefix assignments, any /64 prefix assignments from the ULA | |||
| will eventually be deprecated. | prefix will eventually be deprecated. | |||
| 8. Hysteresis | 8. Hysteresis | |||
| A network may experience temporary connectivity problems, routing | A network may experience temporary connectivity problems, routing | |||
| protocol convergence may take time, and a set of devices may be | protocol convergence may take time, and a set of devices may be | |||
| coming up at the same time due to power being turned on in a | coming up at the same time due to power being turned on in a | |||
| synchronous manner. Due to these reasons it is important that the | synchronous manner. Due to these reasons it is important that the | |||
| prefix allocation and assignment mechanisms do not react before the | prefix allocation and assignment mechanisms do not react before the | |||
| situation is allowed to stabilize. To allow for this, a hysteresis | situation is allowed to stabilize. To allow for this, a hysteresis | |||
| principle is applied to new or withdrawn automatically generated | principle is applied to new or withdrawn automatically generated | |||
| prefixes and prefix assignments. | prefixes and prefix assignments. | |||
| A new automatically generated ULA prefix SHOULD NOT be allocated | A new automatically generated ULA prefix SHOULD NOT be allocated | |||
| before the router has waited NEW_ULA_PREFIX seconds for another | before the router has waited NEW_ULA_PREFIX seconds for another | |||
| prefix or reachable OSPFv3 router to appear. See Section 12 for the | prefix or reachable OSPFv3 router to appear. See Section 12 for the | |||
| specific time value. | specific time value. | |||
| A previously automatically generated ULA prefix SHOULD NOT be taken | A previously automatically generated ULA prefix SHOULD NOT be taken | |||
| out of use before the router has waited TERMINATE_ULA_PREFIX seconds. | out of use before the router has waited TERMINATE_ULA_PREFIX seconds. | |||
| A new prefix assignment within a usable prefix SHOULD NOT be | A new prefix assignment within an aggregated prefix SHOULD NOT be | |||
| committed before the router has waited NEW_PREFIX_ASSIGNMENT seconds | committed before the router has waited NEW_PREFIX_ASSIGNMENT seconds | |||
| for another prefix or reachable OSPFv3 router to appear. Note the | for another prefix or reachable OSPFv3 router to appear. Note the | |||
| exceptions to this rule in Section 6.3.1, item 4. | exceptions to this rule in Section 6.3.1, item 4. | |||
| A previously assigned prefix SHOULD NOT be taken out of use before | A previously assigned prefix SHOULD NOT be taken out of use before | |||
| the router has waited TERMINATE_PREFIX_ASSIGNMENT seconds. | the router has waited TERMINATE_PREFIX_ASSIGNMENT seconds. | |||
| 9. Manageability Considerations | 9. Manageability Considerations | |||
| Advanced users may wish to manage their networks without automation, | Advanced users may wish to manage their networks without automation, | |||
| and there may also be situations where manual intervention may be | and there may also be situations where manual intervention may be | |||
| needed. For these purposes there MUST be a configuration mechanism | needed. For these purposes there MUST be a configuration mechanism | |||
| that allows users to turn off the automatic prefix allocation and | that allows users to turn off the automatic prefix allocation and | |||
| assignment on a given interface. This setting can be a part of | assignment on a given interface. This setting can be a part of | |||
| disabling the entire routing auto-configuration | disabling the entire routing auto-configuration | |||
| [I-D.acee-ospf-ospfv3-autoconfig]. | [I-D.ietf-ospf-ospfv3-autoconfig]. | |||
| In addition, there SHOULD be a configuration mechanism that allows | In addition, there SHOULD be a configuration mechanism that allows | |||
| users to specify the prefix that they would like the router to | users to specify the prefix that they would like the router to | |||
| request for a given interface. This can be useful, for instance, | request for a given interface. This can be useful, for instance, | |||
| when a router is replaced and there is a desire for the new router to | when a router is replaced and there is a desire for the new router to | |||
| be configured to ask for the same prefix as the old one, in order to | be configured to ask for the same prefix as the old one, in order to | |||
| avoid renumbering other devices on this network. | avoid renumbering other devices on this network. | |||
| Finally, there SHOULD be mechanisms to display the prefixes assigned | Finally, there SHOULD be mechanisms to display the prefixes assigned | |||
| on each interface, and where they came from (manual configuration, | on each interface, and where they came from (manual configuration, | |||
| DHCPv6 PD, OSPFv3). | DHCPv6 PD, OSPFv3). | |||
| 10. Security Considerations | 10. Security Considerations | |||
| Security can be always added later. | Security can be always added later. | |||
| 11. IANA Considerations | 11. IANA Considerations | |||
| 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.ietf-ospf-ospfv3-autoconfig]: | |||
| o The Usable Prefix TLV in Section 6.1 takes the value TBD-BY-IANA-1 | o The Aggregated Prefix TLV in Section 6.1 takes the value TBD-BY- | |||
| (suggested value is 2). | IANA-1 (suggested value is 2). | |||
| o The Assigned Prefix TLV in Section 6.2 takes the value TBD-BY- | o The Assigned Prefix TLV in Section 6.2 takes the value TBD-BY- | |||
| IANA-2 (suggested value is 3). | IANA-2 (suggested value is 3). | |||
| 12. Timer Constants | 12. Timer Constants | |||
| NEW_ULA_PREFIX 20 seconds | NEW_ULA_PREFIX 20 seconds | |||
| TERMINATE_ULA_PREFIX 120 seconds | TERMINATE_ULA_PREFIX 120 seconds | |||
| NEW_PREFIX_ASSIGNMENT 20 seconds | NEW_PREFIX_ASSIGNMENT 20 seconds | |||
| TERMINATE_PREFIX_ASSIGNMENT 240 seconds | TERMINATE_PREFIX_ASSIGNMENT 240 seconds | |||
| skipping to change at page 20, line 9 ¶ | skipping to change at page 20, line 30 ¶ | |||
| "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, | |||
| September 2007. | September 2007. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | |||
| for IPv6", RFC 5340, July 2008. | for IPv6", RFC 5340, July 2008. | |||
| [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.ietf-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-ietf-ospf-ospfv3-autoconfig-00 (work in progress), | |||
| October 2011. | October 2012. | |||
| 13.2. Informative References | 13.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.ietf-homenet-arch] | |||
| Arkko, J., Chown, T., Weil, J., and O. Troan, "Home | Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, | |||
| Networking Architecture for IPv6", | "Home Networking Architecture for IPv6", | |||
| draft-chown-homenet-arch-00 (work in progress), | draft-ietf-homenet-arch-06 (work in progress), | |||
| September 2011. | October 2012. | |||
| [I-D.chelius-router-autoconf] | [I-D.chelius-router-autoconf] | |||
| Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for | Chelius, G., Fleury, E., and L. Toutain, "Using OSPFv3 for | |||
| IPv6 router autoconfiguration", | IPv6 router autoconfiguration", | |||
| draft-chelius-router-autoconf-00 (work in progress), | draft-chelius-router-autoconf-00 (work in progress), | |||
| June 2002. | June 2002. | |||
| [I-D.dimitri-zospf] | [I-D.dimitri-zospf] | |||
| Dimitrelis, A. and A. Williams, "Autoconfiguration of | Dimitrelis, A. and A. Williams, "Autoconfiguration of | |||
| routers using a link state routing protocol", | routers using a link state routing protocol", | |||
| draft-dimitri-zospf-00 (work in progress), October 2002. | draft-dimitri-zospf-00 (work in progress), October 2002. | |||
| [SIGCOMM.IPV6] | [SIGCOMM.IPV6] | |||
| Chelius, G., Fleury, E., Sericola, B., Toutain, L., and D. | Chelius, G., Fleury, E., Sericola, B., Toutain, L., and D. | |||
| Binet, "An evaluation of the NAP protocol for IPv6 router | Binet, "An evaluation of the NAP protocol for IPv6 router | |||
| auto-configuration", ACM SIGCOMM IPv6 Workshop, Kyoto, | auto-configuration", ACM SIGCOMM IPv6 Workshop, Kyoto, | |||
| Japan, 2007. | Japan, 2007. | |||
| Appendix A. Acknowledgments | Appendix A. Changes in Version -02 | |||
| These changes were extensive, including the definition of a new | ||||
| algorithm for making allocations, adding support for DNS server | ||||
| discovery, adding support for ULA-based address space generation, and | ||||
| adding specifications for a hysteresis mechanism. | ||||
| Appendix B. Changes in Version -03 | ||||
| This version updated references to the most current ones, and changed | ||||
| the "usable prefix" terminology to "aggregated prefix". The | ||||
| requirements for turning on DNS relays or servers were also | ||||
| clarified. | ||||
| Appendix C. 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, Markus Stenberg, | |||
| Halpern, Samita Chakrabarti, Michael Richardson, Anders Brandt, Erik | Wassim Haddad, Joel Halpern, Samita Chakrabarti, Michael Richardson, | |||
| Nordmark, Laurent Toutain, and Ralph Droms for interesting | Anders Brandt, Erik Nordmark, Laurent Toutain, and Ralph Droms for | |||
| discussions in this problem space. The authors would also like to | interesting discussions in this problem space. The authors would | |||
| point out some past work in this space, such as those in | 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]. | [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. 62 change blocks. | ||||
| 151 lines changed or deleted | 187 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/ | ||||