| draft-pentland-dna-protocol-00.txt | | draft-pentland-dna-protocol-01.txt | |
| | | | |
|
| DNA Working Group S. Narayanan | | DNA Working Group J. Kempf | |
| Internet-Draft Panasonic | | Internet-Draft DoCoMo Communications Labs USA | |
| Expires: November 4, 2005 E. Nordmark | | Expires: January 19, 2006 S. Narayanan | |
| | | Panasonic | |
| | | E. Nordmark | |
| Sun Microsystems | | Sun Microsystems | |
|
| B. Pentland | | B. Pentland, Ed. | |
| Monash University CTIE | | Monash University CTIE | |
|
| May 3, 2005 | | July 18, 2005 | |
| | | | |
| Detecting Network Attachment in IPv6 Networks (DNAv6) | | Detecting Network Attachment in IPv6 Networks (DNAv6) | |
|
| draft-dnadt-dna-protocol-00.txt | | draft-pentland-dna-protocol-01.txt | |
| | | | |
| Status of this Memo | | Status of this Memo | |
| | | | |
| By submitting this Internet-Draft, each author represents that any | | By submitting this Internet-Draft, each author represents that any | |
| applicable patent or other IPR claims of which he or she is aware | | applicable patent or other IPR claims of which he or she is aware | |
| have been or will be disclosed, and any of which he or she becomes | | have been or will be disclosed, and any of which he or she becomes | |
| aware will be disclosed, in accordance with Section 6 of BCP 79. | | aware will be disclosed, in accordance with Section 6 of BCP 79. | |
| | | | |
| Internet-Drafts are working documents of the Internet Engineering | | Internet-Drafts are working documents of the Internet Engineering | |
| Task Force (IETF), its areas, and its working groups. Note that | | Task Force (IETF), its areas, and its working groups. Note that | |
| | | | |
| skipping to change at page 1, line 37 | | skipping to change at page 1, line 39 | |
| 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." | |
| | | | |
| The list of current Internet-Drafts can be accessed at | | The list of current Internet-Drafts can be accessed at | |
| http://www.ietf.org/ietf/1id-abstracts.txt. | | http://www.ietf.org/ietf/1id-abstracts.txt. | |
| | | | |
| The list of Internet-Draft Shadow Directories can be accessed at | | The list of Internet-Draft Shadow Directories can be accessed at | |
| http://www.ietf.org/shadow.html. | | http://www.ietf.org/shadow.html. | |
| | | | |
|
| This Internet-Draft will expire on November 4, 2005. | | This Internet-Draft will expire on January 19, 2006. | |
| | | | |
| Copyright Notice | | Copyright Notice | |
| | | | |
| Copyright (C) The Internet Society (2005). | | Copyright (C) The Internet Society (2005). | |
| | | | |
| Abstract | | Abstract | |
| | | | |
| Efficient detection of network attachment in IPv6 needs the following | | Efficient detection of network attachment in IPv6 needs the following | |
| two components: a method for the host to query routers on the link to | | two components: a method for the host to query routers on the link to | |
| identify the link (Link Identification) and a method for the routers | | identify the link (Link Identification) and a method for the routers | |
| on the link to consistently respond to such a query with minimal | | on the link to consistently respond to such a query with minimal | |
| delay (Fast RA). Solving the link identification based strictly on | | delay (Fast RA). Solving the link identification based strictly on | |
| RFC 2461 is difficult because of the flexibilities offered to routers | | RFC 2461 is difficult because of the flexibilities offered to routers | |
| in terms of prefixes advertised in a router advertisement (RA) | | in terms of prefixes advertised in a router advertisement (RA) | |
| message. Similarly, the random delay in responding to router | | message. Similarly, the random delay in responding to router | |
| solicitation messages imposed by RFC 2461 makes to it difficult to | | solicitation messages imposed by RFC 2461 makes to it difficult to | |
|
| achive fast RA. A known set of solutions to these two problems were | | achieve fast RA. A known set of solutions to these two problems was | |
| identified and catalogued by the DNA design team. In this memo, an | | identified and catalogued by the DNA design team. In this memo, an | |
| integrated solution is presented, based on a sub-set of the | | integrated solution is presented, based on a sub-set of the | |
| catalogued solutions. This integrated solution consolidates most of | | catalogued solutions. This integrated solution consolidates most of | |
| the advantages of all known solutions while addressing most of the | | the advantages of all known solutions while addressing most of the | |
| disadvantages. | | disadvantages. | |
| | | | |
| Table of Contents | | Table of Contents | |
| | | | |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
| | | | |
| 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 | | 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 | |
| | | | |
| 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
| 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 | | 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 | |
| 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 | | 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 | |
|
| 3.3 Fast Router Advertisment . . . . . . . . . . . . . . . . . 7 | | 3.3 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 | |
| | | | |
| 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 | | 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 | |
| 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8 | | 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8 | |
| 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9 | | 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9 | |
| 4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10 | | 4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10 | |
| | | | |
|
| 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 | | 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 | |
| 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 11 | | 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 12 | |
| 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 11 | | 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 12 | |
| 5.1.2 Router Configuration Variables . . . . . . . . . . . . 12 | | 5.1.2 Router Configuration Variables . . . . . . . . . . . . 13 | |
| 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 13 | | 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 14 | |
| 5.1.4 Processing Router Advertisements . . . . . . . . . . . 13 | | 5.1.4 Processing Router Advertisements . . . . . . . . . . . 15 | |
| 5.1.5 Processing Router Solicitations . . . . . . . . . . . 13 | | 5.1.5 Processing Router Solicitations . . . . . . . . . . . 15 | |
| 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 15 | | 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 16 | |
| 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15 | | 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 16 | |
| 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16 | | 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 17 | |
| 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16 | | 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 17 | |
| 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 | | 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 17 | |
| 5.2.2 Selection of a Landmark Prefix . . . . . . . . . . . . 17 | | 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 18 | |
| 5.2.3 Sending Router Solicitations . . . . . . . . . . . . . 17 | | 5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 18 | |
| 5.2.4 Processing Router Advertisements . . . . . . . . . . . 17 | | 5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 19 | |
| | | 5.2.5 Processing Router Advertisements . . . . . . . . . . . 19 | |
| 6. Backward Compatability . . . . . . . . . . . . . . . . . . . . 18 | | 5.2.6 DNA and Address Configuration . . . . . . . . . . . . 20 | |
| 6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 18 | | | |
| 6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 18 | | | |
| | | | |
|
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | | 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23 | |
| 7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 19 | | 6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 23 | |
| 7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 19 | | 6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 24 | |
| 7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 20 | | | |
| | | | |
|
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |
| | | 7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 24 | |
| | | 7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 24 | |
| | | 7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 25 | |
| | | | |
|
| 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 | | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 | |
| | | | |
|
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 | | 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |
| | | | |
|
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 | |
| 11.1 Normative References . . . . . . . . . . . . . . . . . . . 22 | | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |
| 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 | | 11.1 Normative References . . . . . . . . . . . . . . . . . . . 26 | |
| | | 11.2 Informative References . . . . . . . . . . . . . . . . . . 27 | |
| | | | |
|
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 | | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 | |
| | | | |
|
| A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 23 | | A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 28 | |
| | | | |
|
| Intellectual Property and Copyright Statements . . . . . . . . 25 | | Intellectual Property and Copyright Statements . . . . . . . . 30 | |
| | | | |
| 1. Introduction | | 1. Introduction | |
| | | | |
| The proposed scheme in this memo is built upon the following | | The proposed scheme in this memo is built upon the following | |
|
| solutions catalogued in [12]: Complete RA and Requested Landmark are | | solutions catalogued in [15]: Complete RA and Requested Landmark are | |
| used for the link identification, and Hash-based Fast RA is used to | | used for the link identification, and Hash-based Fast RA is used to | |
| achieve fast response to RS messages. The reasoning behind these | | achieve fast response to RS messages. The reasoning behind these | |
| choices will become evident as the whole scheme and its advantages | | choices will become evident as the whole scheme and its advantages | |
| are understood. | | are understood. | |
| | | | |
| 2. Terms and Abbreviations | | 2. Terms and Abbreviations | |
| | | | |
|
| There is an existing DNA terminology draft [9]. This draft does not | | There is an existing DNA terminology draft [12]. This draft does not | |
| introduce any new terminology not already used by existing drafts. | | introduce any new terminology not already used by existing drafts. | |
| | | | |
| The term "link" is used as defined in RFC 2460 [2]. NOTE: this is | | The term "link" is used as defined in RFC 2460 [2]. NOTE: this is | |
| completely different from the term "link" as used by IEEE 802, etc. | | completely different from the term "link" as used by IEEE 802, etc. | |
| | | | |
| 3. Overview | | 3. Overview | |
| | | | |
| The DNA protocol presented in this document tries to achieve the | | The DNA protocol presented in this document tries to achieve the | |
| following objectives: | | following objectives: | |
| | | | |
| o Eliminate the delays introduced by RFC 2461 in discovering the | | o Eliminate the delays introduced by RFC 2461 in discovering the | |
|
| configuration | | configuration. | |
| | | | |
| o Make it possible for the hosts to accurately detect the identity | | o Make it possible for the hosts to accurately detect the identity | |
|
| of their current link from a single RA | | of their current link from a single RA. | |
| | | | |
| o Keep the packets relatively small in size. | | o Keep the packets relatively small in size. | |
| | | | |
| The approach described in this memo is based on the combination of | | The approach described in this memo is based on the combination of | |
| Requested Landmark and CompleteRA for link identification and the | | Requested Landmark and CompleteRA for link identification and the | |
|
| hash-based Fast RA mechanism. The rest of the document refers to | | Hash-based Fast RA mechanism. The rest of the document refers to | |
| this approach by the term "DNAv6". | | this approach by the term "DNAv6". | |
| | | | |
| DNAv6 assumes that the host's wireless link interface software and | | DNAv6 assumes that the host's wireless link interface software and | |
| hardware is capable of delivering a 'link up' event notification when | | hardware is capable of delivering a 'link up' event notification when | |
| layer 2 on the host is configured and sufficiently stable for IP | | layer 2 on the host is configured and sufficiently stable for IP | |
| traffic. This event notification acts as a hint to the layer 3 DNA | | traffic. This event notification acts as a hint to the layer 3 DNA | |
| procedures to check whether or not the host is attached to the same | | procedures to check whether or not the host is attached to the same | |
| link as before. DNAv6 also assumes that an interface on the host is | | link as before. DNAv6 also assumes that an interface on the host is | |
| never connected to two links at the same time. In the case that the | | never connected to two links at the same time. In the case that the | |
| layer 2 technology is capable of having multiple attachments (for | | layer 2 technology is capable of having multiple attachments (for | |
| | | | |
| skipping to change at page 7, line 16 | | skipping to change at page 7, line 16 | |
| information consists of the prefixes a router would advertise itself | | information consists of the prefixes a router would advertise itself | |
| as per RFC 2461, and also, the prefixes learned from other routers on | | as per RFC 2461, and also, the prefixes learned from other routers on | |
| the link that are not being advertised by itself. These learned | | the link that are not being advertised by itself. These learned | |
| prefixes are included in a new DNA Option in the Router | | prefixes are included in a new DNA Option in the Router | |
| Advertisement. | | Advertisement. | |
| | | | |
| When the resulting multicast RA carries all the prefixes known to the | | When the resulting multicast RA carries all the prefixes known to the | |
| router, the RA is marked as "complete" using a new bit in the | | router, the RA is marked as "complete" using a new bit in the | |
| message. When a host receives a complete multicast RA, the host can | | message. When a host receives a complete multicast RA, the host can | |
| easily decide whether it is attached to the same link or not from the | | easily decide whether it is attached to the same link or not from the | |
|
| single RA. Thus, unlike CPL [11], the host does not have to wait for | | single RA. Thus, unlike CPL [14], the host does not have to wait for | |
| multiple advertisements before making a decision. | | multiple advertisements before making a decision. | |
| | | | |
| In order for the routers be able to both respond to the landmark | | In order for the routers be able to both respond to the landmark | |
| questions and send the complete RAs, the routers need to track the | | questions and send the complete RAs, the routers need to track the | |
| prefixes that other routers advertise on the link. This process is | | prefixes that other routers advertise on the link. This process is | |
| initialized when a router is enabled, by sending a Router | | initialized when a router is enabled, by sending a Router | |
| Solicitation and collecting the resulting RAs, and then multicasting | | Solicitation and collecting the resulting RAs, and then multicasting | |
| a few RAs more rapidly as already suggested in RFC 2461. This | | a few RAs more rapidly as already suggested in RFC 2461. This | |
| process ensures with high probability that all the routers have the | | process ensures with high probability that all the routers have the | |
| same notion of the set of prefixes assigned to the link. | | same notion of the set of prefixes assigned to the link. | |
| | | | |
|
| 3.3 Fast Router Advertisment | | 3.3 Fast Router Advertisement | |
| | | | |
| According to RFC 2461 a solicited Router Advertisement should have a | | According to RFC 2461 a solicited Router Advertisement should have a | |
| random delay between 0 and 500 milliseconds, to avoid the | | random delay between 0 and 500 milliseconds, to avoid the | |
| advertisements from all the routers colliding on the link causing | | advertisements from all the routers colliding on the link causing | |
| congestion and higher probability of packet loss. In addition, RFC | | congestion and higher probability of packet loss. In addition, RFC | |
| 2461 suggests that the RAs be multicast, and multicast RAs are rate | | 2461 suggests that the RAs be multicast, and multicast RAs are rate | |
| limited to one message every 3 seconds. This implies that the | | limited to one message every 3 seconds. This implies that the | |
| response to a RS might be delayed up to 3.5 seconds. | | response to a RS might be delayed up to 3.5 seconds. | |
| | | | |
| DNAv6 avoids this delay by using a different mechanism to ensure that | | DNAv6 avoids this delay by using a different mechanism to ensure that | |
| | | | |
| skipping to change at page 10, line 38 | | skipping to change at page 10, line 38 | |
| Prefix | | Prefix | |
| | | | |
| A prefix being used by the host currently for a global IPv6 | | A prefix being used by the host currently for a global IPv6 | |
| address, padded at the right with zeros. If the prefix length is | | address, padded at the right with zeros. If the prefix length is | |
| less than 65 bits, only 64 bits need be included, otherwise 128 | | less than 65 bits, only 64 bits need be included, otherwise 128 | |
| bits are included. | | bits are included. | |
| | | | |
| 4.3 DNA Option | | 4.3 DNA Option | |
| | | | |
| The DNA Option (DNAO) is used by a router to indicate prefixes that | | The DNA Option (DNAO) is used by a router to indicate prefixes that | |
|
| are being advertised in PIOs by other routers on the link, but not | | are being advertised in PIOs by other routers on the link, but not by | |
| itself. | | itself. | |
| | | | |
| 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 | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
|
| | Type | Length | Learned Prefixes ... | | | | Type | Length | Prefix Len 1 | Prefix Len 2 | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| ~ ~ | | | ... | Prefix Len N | Padding | | |
| | ... Padding | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | | | | |
| | | + + | |
| | | | | | |
| | | + Prefix 1 + | |
| | | | | | |
| | | + + | |
| | | | | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
|
| | | | | | |
| | | + + | |
| | | | | | |
| | | + Prefix 2 + | |
| | | | | | |
| | | + + | |
| | | | | | |
| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | ~ ... | |
| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | | | | |
| | | + + | |
| | | | | | |
| | | + Prefix N + | |
| | | | | | |
| | | + + | |
| | | | | | |
| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | | |
| Type | | Type | |
| | | | |
| TBA | | TBA | |
| | | | |
| Length | | Length | |
| | | | |
| 8 bit unsigned integer indicating the length of the option in | | 8 bit unsigned integer indicating the length of the option in | |
| units of 8 octets. | | units of 8 octets. | |
| | | | |
|
| Learned Prefixes | | Prefix Len | |
| | | One or more fields (N) each consisting of an 8-bit unsigned | |
| Zero or more fields each consisting of an 8-bit prefix length | | integer representing the prefix lengths of the following prefixes. | |
| followed by a 128-bit address representing a prefix that has been | | The Prefix Len fields are ordered the same as the Prefix fields so | |
| heard on the link but is not explicitly configured on this router. | | that the first Prefix Len field represents the prefix length of | |
| | | the prefix contained in the first prefix field, and so on. | |
| | | | |
| Padding | | Padding | |
| | | | |
|
| Zero padding to make the option an integer multiple of 8 octets. | | Zero padding sufficient to align the following prefix field on an | |
| | | 8-octet boundary. | |
| | | | |
| | | Prefix | |
| | | | |
| | | One or more fields (N) each containing a 128-bit address | |
| | | representing a prefix that has been heard on the link but is not | |
| | | explicitly configured on this router. | |
| | | | |
| Description | | Description | |
| | | | |
| This option MUST only be included in a Router Advertisement. This | | This option MUST only be included in a Router Advertisement. This | |
| option contains prefixes that are being advertised on the link but | | option contains prefixes that are being advertised on the link but | |
| are not explicitly configured on the sending router. The router | | are not explicitly configured on the sending router. The router | |
| MUST NOT include any prefixes with a zero valid lifetime in the | | MUST NOT include any prefixes with a zero valid lifetime in the | |
| DNAO. | | DNAO. | |
| | | | |
|
| NOTE: Some discussion is needed on the best format for this | | | |
| option. | | | |
| | | | |
| 5. DNA Operation | | 5. DNA Operation | |
| | | | |
| 5.1 DNA Router Operation | | 5.1 DNA Router Operation | |
| | | | |
| Routers MUST collect information about the other routers that are | | Routers MUST collect information about the other routers that are | |
| advertising on the link. | | advertising on the link. | |
| | | | |
| 5.1.1 Data Structures | | 5.1.1 Data Structures | |
| | | | |
| The routers maintain a set of conceptual data structures for each | | The routers maintain a set of conceptual data structures for each | |
| interface to track the prefixes advertised by other routers on the | | interface to track the prefixes advertised by other routers on the | |
| link, and also the set of DNA routers (the routers that will quickly | | link, and also the set of DNA routers (the routers that will quickly | |
|
| respond to RAs) on the link. For each interface, routers maintain a | | respond to RSs) on the link. | |
| list of all prefixes advertised on the link. The list will be | | | |
| referred to in this document as "DNAPrefixList". For each prefix the | | For each interface, routers maintain a list of all prefixes | |
| router MUST store the following information: | | advertised on the link. The list will be referred to in this | |
| | | document as "DNAPrefixList". For each prefix the router MUST store | |
| | | sufficient information to identify the prefix and to know when to | |
| | | remove the prefix entry from the list. This may be achieved by | |
| | | storing the following information: | |
| | | | |
| 1. Prefix | | 1. Prefix | |
| | | | |
| 2. Prefix length | | 2. Prefix length | |
| | | | |
| 3. Valid lifetime | | 3. Valid lifetime | |
| | | | |
| 4. Time last refreshed | | 4. Time last refreshed | |
| | | | |
| For each interface, routers also maintain a list of the other routers | | For each interface, routers also maintain a list of the other routers | |
| advertising on the link. The list will be referred to in this memo | | advertising on the link. The list will be referred to in this memo | |
| as "DNARouterList". For each router from which a Router | | as "DNARouterList". For each router from which a Router | |
| Advertisement is received with the DNA flag set, the following | | Advertisement is received with the DNA flag set, the following | |
| information MUST be stored: | | information MUST be stored: | |
| | | | |
| 1. Source address of advertising router | | 1. Source address of advertising router | |
| | | | |
| 2. Token equal to the first 64 bits of an SHA-1 hash of the above | | 2. Token equal to the first 64 bits of an SHA-1 hash of the above | |
| address | | address | |
| | | | |
|
| | | 3. Time last refreshed | |
| | | | |
| Each router MUST include itself in the DNARouterList and generate a | | Each router MUST include itself in the DNARouterList and generate a | |
| token for itself as describe above based on the link-local address | | token for itself as describe above based on the link-local address | |
| used in its RA messages. | | used in its RA messages. | |
| | | | |
| 5.1.2 Router Configuration Variables | | 5.1.2 Router Configuration Variables | |
| | | | |
| A DNAv6 router MUST allow for the following conceptual variables to | | A DNAv6 router MUST allow for the following conceptual variables to | |
| be configured by the system management. Default values are set to | | be configured by the system management. Default values are set to | |
|
| ease configuation load. | | ease configuration load. | |
| | | | |
| UnicastRAInterval | | UnicastRAInterval | |
| | | | |
| The interval corresponding to the maximum average rate of Router | | The interval corresponding to the maximum average rate of Router | |
| Solicitations that the router is prepared to service with unicast | | Solicitations that the router is prepared to service with unicast | |
| responses. This is the interval at which the token bucket | | responses. This is the interval at which the token bucket | |
| controlling the unicast responses is replenished. | | controlling the unicast responses is replenished. | |
| | | | |
| Default: 50 milliseconds | | Default: 50 milliseconds | |
| | | | |
| | | | |
| skipping to change at page 13, line 21 | | skipping to change at page 14, line 21 | |
| | | | |
| Default: 20 milliseconds | | Default: 20 milliseconds | |
| | | | |
| MulticastRADelay | | MulticastRADelay | |
| | | | |
| The delay to be introduced when scheduling a multicast RA in | | The delay to be introduced when scheduling a multicast RA in | |
| response to a RS message when the token bucket is empty. | | response to a RS message when the token bucket is empty. | |
| | | | |
| Default: 3000 milliseconds | | Default: 3000 milliseconds | |
| | | | |
|
| | | FastRAThreshold | |
| | | | |
| | | The maximum number of fast responses that a host should receive | |
| | | when soliciting for Router Advertisements. | |
| | | | |
| | | Default: 3 | |
| | | | |
| 5.1.3 Bootstrapping DNA Data Structures | | 5.1.3 Bootstrapping DNA Data Structures | |
| | | | |
| When an interface on a router first starts up, it SHOULD transmit up | | When an interface on a router first starts up, it SHOULD transmit up | |
| to MAX_RTR_SOLICITATIONS Router Solicitations separated by | | to MAX_RTR_SOLICITATIONS Router Solicitations separated by | |
| RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other | | RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other | |
| routers and prefixes active on the link. | | routers and prefixes active on the link. | |
| | | | |
|
| | | Upon startup, a router interface SHOULD also send a few unsolicited | |
| | | Router Advertisements as recommended in Section 6.2.4 of RFC 2461 | |
| | | [3], in order to inform others routers on the link of its presence. | |
| | | | |
| | | During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * | |
| | | RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface | |
| | | both sends unsolicited Router Advertisements and responds to Router | |
| | | Solicitations, but with a few restrictions on the message content. | |
| | | Router Advertisements MUST NOT include any DNA specific options | |
| | | except that the DNA flag MUST be set. The DNA flag is set so that | |
| | | other routers will know to include this router in their timing | |
| | | calculations for fast RA transmission. Other DNA options are omitted | |
| | | because the router may have incomplete information during bootstrap. | |
| | | | |
| | | During the bootstrap period, the timing of Router Advertisement | |
| | | transmission is as specified in RFC 2461. | |
| | | | |
| 5.1.4 Processing Router Advertisements | | 5.1.4 Processing Router Advertisements | |
| | | | |
| When a router receives a Router Advertisement, it first validates the | | When a router receives a Router Advertisement, it first validates the | |
|
| RA per the rules in RFC 2461, and then performs the actions specified | | RA as per the rules in RFC 2461, and then performs the actions | |
| in RFC 2461. In addition, each valid Router Advertisement is | | specified in RFC 2461. In addition, each valid Router Advertisement | |
| processed as follows: | | is processed as follows: | |
| | | | |
| If the DNA flag is set in the RA, the router checks if there is an | | If the DNA flag is set in the RA, the router checks if there is an | |
| entry in its DNARouterList. Thus it looks up the source address of | | entry in its DNARouterList. Thus it looks up the source address of | |
| the RA in that list and, if not found, a new entry is added to | | the RA in that list and, if not found, a new entry is added to | |
| DNARouterList, including the source address and a token equal to the | | DNARouterList, including the source address and a token equal to the | |
| first 64 bits of an SHA-1 hash of the source address. The entry's | | first 64 bits of an SHA-1 hash of the source address. The entry's | |
| 'Time last refreshed' is updated. | | 'Time last refreshed' is updated. | |
| | | | |
| Regardless of the state of the DNA flag, each PIO in the RA is | | Regardless of the state of the DNA flag, each PIO in the RA is | |
|
| examined. If the prefix is not in the router's AdvPrefixList [3] and | | examined. If the prefix is not in the router's DNAPrefixList, it is | |
| not already in the DNAPrefixList, it is added to the DNAPrefixList, | | added, along with the lifetime and refresh information. | |
| along with the lifetime and refresh information. | | | |
| | | | |
| 5.1.5 Processing Router Solicitations | | 5.1.5 Processing Router Solicitations | |
| | | | |
|
| The usual response to an RS SHOULD be a unicast RA. To keep control | | The usual response to an RS SHOULD be a unicast RA. However, to keep | |
| of the number of unicast RAs sent, a token bucket is used to limit | | control of the rate of unicast RAs sent, a token bucket is used. The | |
| the rate at which they are sent. The token bucket is filled at one | | token bucket is filled at one token every UnicastRAInterval. A | |
| token every UnicastRAInterval. A maximum of MaxUnicastRABurst tokens | | maximum of MaxUnicastRABurst tokens are stored. | |
| are stored. | | | |
| | | | |
| The router interface switches bewteen two states with respect to | | | |
| Router Solicitation response, depending on the availablity of tokens | | | |
| in the token bucket. The states are called UnicastSender and | | | |
| MulticastSender. The interface MUST be initialised to the | | | |
| UnicastSender state and the token bucket to full. | | | |
| | | | |
|
| If the interface is in the UnicastSender state then the router checks | | When a Router Solicitation is received, if a unicast send token is | |
| whether there are any unicast send tokens available. If a unicast | | available then: | |
| send token is available: | | | |
| | | | |
| If the source address of the Router Solicitation is the | | If the source address of the Router Solicitation is the | |
|
| Unspecified Address or if it does not contain a landmark option, | | Unspecified Address, then the router builds a Complete RA as | |
| then the router builds a CompleteRA and schedules it for multicast | | specified in Section 5.1.6 and schedules it for multicast | |
| transmission as per RFC 2461. The interface MUST remain in the | | transmission as per RFC 2461. | |
| UnicastSender state. | | | |
| | | | |
| If the source address of the RS is NOT the unspecified address, | | If the source address of the RS is NOT the unspecified address, | |
|
| AND the RS message contains a Landmark option, the router consumes | | the router consumes one unicast send token and then builds a | |
| one unicast send token and then builds a Router Advertisement as | | Router Advertisement as follows: | |
| follows: | | | |
| | | | |
| The DNA flag is set. | | The DNA flag is set. | |
| | | | |
| If the RS contains a Landmark Option whose prefix matches one | | If the RS contains a Landmark Option whose prefix matches one | |
|
| of those in the interface's stored prefix list, then the | | of those in the interface's DNAPrefixList, then the Landmark | |
| Landmark option with the Landmark prefix is included in the RA | | option with the Landmark prefix is included in the RA but with | |
| but with the Yes flag set. At this point the RA is ready for | | the Yes flag set. All configuration related options (MTU, | |
| transmission, and is scheduled as specified in Section 5.1.7. | | Advertisement Interval, etc., including PIOs) SHOULD NOT be | |
| | | included as this information is already known to the host. | |
| | | SEND options, if any, MUST NOT be omitted. At this point the | |
| | | RA is ready for transmission, and is scheduled as specified in | |
| | | Section 5.1.7. | |
| | | | |
| If the RS contains a Landmark Option whose prefix does not | | If the RS contains a Landmark Option whose prefix does not | |
| match any of those in the interface's stored prefix list, then | | match any of those in the interface's stored prefix list, then | |
| the Landmark option with the Landmark prefix is included in the | | the Landmark option with the Landmark prefix is included in the | |
| RA but with the No flag set. All fixed options (MTU, | | RA but with the No flag set. All fixed options (MTU, | |
| Advertisement Interval, flags, etc.) are added to the Router | | Advertisement Interval, flags, etc.) are added to the Router | |
| Advertisement. Prefix Information Options for any explicitly | | Advertisement. Prefix Information Options for any explicitly | |
| configured prefixes SHOULD be added to the Router | | configured prefixes SHOULD be added to the Router | |
|
| Advertisement, while the DNAO for learned prefixes MUST not be | | Advertisement, while the DNAO for learned prefixes SHOULD NOT | |
| added. If there is insufficent room to fit all of the PIOs, an | | be added. If there is insufficient room to fit all of the | |
| additional Router Advertisement is built after consuming | | PIOs, an additional Router Advertisement is built after | |
| another token, if available. At this point the Router | | consuming another token, if available. At this point the | |
| Advertisment is ready for transmission, and is scheduled as | | Router Advertisement is ready for transmission, and is | |
| specified in Section 5.1.7. | | scheduled as specified in Section 5.1.7. | |
| | | | |
|
| If the interface is in UnicastSender state and a unicast send token | | If the RS does not contain a Landmark Option, then the router | |
| is not available in the token bucket, the router MUST start a timer | | builds a complete RA as specified in Section 5.1.6 and | |
| (MulticastTimer) to expire after MulticastRADelay. The interface | | schedules it for unicast transmission as specified in | |
| MUST transition to the MulticastSender state. | | Section 5.1.7. | |
| | | | |
|
| If a Router Solicitation is received when the interface is in the | | If no unicast send token is available in the token bucket, AND there | |
| MulticastSender state, then the Router Solicitation MUST be dropped. | | are no existing scheduled multicast RAs, the router MUST construct a | |
| A multicast Router Advertisement has already been scheduled. | | Complete RA as specified in Section 5.1.6 and schedule it for | |
| | | transmission after MulticastRADelay. | |
| | | | |
|
| When the MulticastTimer expires, the router MUST schedule a multicast | | Otherwise it is not possible to send a fast unicast response and a | |
| RA for transmission. This multicast RA SHOULD be constructed as a | | multicast Complete RA is already scheduled so therefore the Router | |
| CompleteRA, as specified in Section 5.1.6. After transmission of | | Solicitation MUST be dropped. | |
| this multicast Router Advertisement in MulticastSenderState, the | | | |
| interface MUST transision to the UnicastSender state. | | | |
| | | | |
| 5.1.6 Complete Router Advertisements | | 5.1.6 Complete Router Advertisements | |
| | | | |
| A CompleteRA is formed as follows: | | A CompleteRA is formed as follows: | |
| | | | |
| Starting with a Router Advertisement with all fixed options (MTU, | | Starting with a Router Advertisement with all fixed options (MTU, | |
| Advertisement Interval, flags, etc.), the DNA flag is set. As many | | Advertisement Interval, flags, etc.), the DNA flag is set. As many | |
| Prefix Information Options for explicitly configured prefixes as will | | Prefix Information Options for explicitly configured prefixes as will | |
| fit are added to the Router Advertisement. If there is sufficient | | fit are added to the Router Advertisement. If there is sufficient | |
| room, a DNA option as defined in Section 4.3 containing as many of | | room, a DNA option as defined in Section 4.3 containing as many of | |
| | | | |
| skipping to change at page 15, line 46 | | skipping to change at page 17, line 13 | |
| RAs may need to be delayed to avoid collisions in the case that there | | RAs may need to be delayed to avoid collisions in the case that there | |
| is more than one router on a link. The delay is calculated by | | is more than one router on a link. The delay is calculated by | |
| determining a ranking for the router for the received RS, and | | determining a ranking for the router for the received RS, and | |
| multiplying that by RASeparation. | | multiplying that by RASeparation. | |
| | | | |
| A token is needed from the RS to calculate the router's ranking. The | | A token is needed from the RS to calculate the router's ranking. The | |
| low order 64 bits of the RS source address MUST be used as the RS | | low order 64 bits of the RS source address MUST be used as the RS | |
| token. | | token. | |
| | | | |
| A router's ranking is determined by taking the XOR of the RS token | | A router's ranking is determined by taking the XOR of the RS token | |
|
| and each of the stored router tokens. The result of this XOR | | and each of the stored router tokens. The results of these XOR | |
| operation is a 64-bit number. For the purpose of comparison it is | | operations are sorted lowest to highest, doing comparisons byte-by- | |
| treated as an unsigned integer. The lowest result is ranked zero, | | byte starting with the least significant byte. The router | |
| | | corresponding to the first entry in the sorted list is ranked zero, | |
| the second, one, and so on. | | the second, one, and so on. | |
| | | | |
|
| The RA MUST be scheduled for transmission in Rank * RASeparation | | Note: it is not necessary for a router to actually sort the whole | |
| milliseconds. When the router is ranked as zero, the resulting delay | | list. Each router just needs to determine its own position in the | |
| is zero, thus the RA SHOULD be sent immediately. | | sorted list. | |
| | | | |
| | | If Rank < FastRAThreshold, then the RA MUST be scheduled for | |
| | | transmission in Rank * RASeparation milliseconds. When the router is | |
| | | ranked as zero, the resulting delay is zero, thus the RA SHOULD be | |
| | | sent immediately. | |
| | | | |
| | | If Rank >= FastRAThreshold, then the RA MUST be replaced with a | |
| | | Complete RA, if it is not one already, and scheduled for multicast | |
| | | transmission as in RFC 2461. | |