| rfc7984v1.txt | rfc7984.txt | |||
|---|---|---|---|---|
| skipping to change at page 2, line 24 | skipping to change at page 2, line 24 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 3 | 3. DNS Procedures in a Dual-Stack Network . . . . . . . . . . . 3 | |||
| 3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 3 | 3.1. Dual-Stack SIP UA DNS Record Lookup Procedure . . . . . . 3 | |||
| 3.2. Indicating Address Family Preference in DNS SRV Records . 4 | 3.2. Indicating Address Family Preference in DNS SRV Records . 4 | |||
| 4. Clarification of Interaction with RFC 6724 . . . . . . . . . 5 | 4. Clarification of Interaction with RFC 6724 . . . . . . . . . 5 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 8 | 6.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 1. Introduction | 1. Introduction | |||
| The Session Initiation Protocol (SIP) [RFC3261] and the additional | The Session Initiation Protocol (SIP) [RFC3261] and the additional | |||
| documents that extended it provide support for both IPv4 and IPv6. | documents that extended it provide support for both IPv4 and IPv6. | |||
| However, this support does not fully extend to the highly hybridized | However, this support does not fully extend to the highly hybridized | |||
| environments that are characteristic of the transitional migratory | environments that are characteristic of the transitional migratory | |||
| phase from IPv4 to IPv6 networks. During this phase, many server and | phase from IPv4 to IPv6 networks. During this phase, many server and | |||
| client implementations run on dual-stack hosts. In such | client implementations run on dual-stack hosts. In such | |||
| environments, a dual-stack host will likely suffer greater connection | environments, a dual-stack host will likely suffer greater connection | |||
| skipping to change at page 5, line 16 | skipping to change at page 5, line 16 | |||
| Unfortunately, in common SIP situations, it is not possible to "race" | Unfortunately, in common SIP situations, it is not possible to "race" | |||
| simultaneous request attempts using two address families. If the SIP | simultaneous request attempts using two address families. If the SIP | |||
| requests are transmitted as single UDP packets, sending two copies of | requests are transmitted as single UDP packets, sending two copies of | |||
| the request to two different addresses risks having two copies of the | the request to two different addresses risks having two copies of the | |||
| request propagating through the SIP network at the same time. The | request propagating through the SIP network at the same time. The | |||
| difference between SIP and HTTP is that in SIP, the sender cannot | difference between SIP and HTTP is that in SIP, the sender cannot | |||
| test a route in a non-state-changing way. | test a route in a non-state-changing way. | |||
| (If two copies of the same request arrive at the destination client, | (If two copies of the same request arrive at the destination client, | |||
| the client MUST reject the second of them with a 482 "Merged Request" | the client SHOULD reject the second of them with a response code of | |||
| response [RFC3261]. But this rule is not sufficient to prevent user- | 482 [RFC3261]. To convey information on why the request was rejected | |||
| visible differences in behavior. A proxy that is upstream of the | to the originator, the client can include a descriptive reason | |||
| second request to arrive at the client may (almost immediately!) | phrase, for example, "Merged Request". But this rule is not | |||
| serially fork the second request to further destinations (e.g., the | sufficient to prevent user-visible differences in behavior. A proxy | |||
| voicemail service for the destination client).) | that is upstream of the second request to arrive at the client may | |||
| (almost immediately!) serially fork the second request to further | ||||
| destinations (e.g., the voicemail service for the destination | ||||
| client).) | ||||
| In this common scenario, it is often necessary for a dual-stack | In this common scenario, it is often necessary for a dual-stack | |||
| client to indicate a preference for either IPv4 or IPv6. A service | client to indicate a preference for either IPv4 or IPv6. A service | |||
| may use DNS SRV records to indicate such a preference for an address | may use DNS SRV records to indicate such a preference for an address | |||
| family. This way, a server with a high-latency and/or low-capacity | family. This way, a server with a high-latency and/or low-capacity | |||
| IPv4 tunnel may indicate a preference for being contacted using IPv6. | IPv4 tunnel may indicate a preference for being contacted using IPv6. | |||
| A server that wishes to do this can use the lowest SRV priority to | A server that wishes to do this can use the lowest SRV priority to | |||
| publish host names that only resolve in IPv6 and the next priority | publish host names that only resolve in IPv6 and the next priority | |||
| with host names that resolve in both address families. | with host names that resolve in both address families. | |||
| skipping to change at page 6, line 23 | skipping to change at page 6, line 26 | |||
| For example, consider a server with DNS name example.com, with TCP | For example, consider a server with DNS name example.com, with TCP | |||
| transport specified. The relevant SRV records for example.com are: | transport specified. The relevant SRV records for example.com are: | |||
| _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. | _sip._tcp.example.com. 300 IN SRV 10 1 5060 sip-1.example.com. | |||
| _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. | _sip._tcp.example.com. 300 IN SRV 20 1 5060 sip-2.example.com. | |||
| The processing of [RFC2782] results in this ordered list of target | The processing of [RFC2782] results in this ordered list of target | |||
| domain names: | domain names: | |||
| sip-1.example.com sip-2.example.com | sip-1.example.com | |||
| sip-2.example.com | ||||
| The address records for sip-1.example.com, as ordered by [RFC6724], | The address records for sip-1.example.com, as ordered by [RFC6724], | |||
| are: | are: | |||
| sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face | sip-1.example.com. 300 IN AAAA 2001:0db8:58:c02::face | |||
| sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe | sip-1.example.com. 300 IN AAAA 2001:0db8:c:a06::2:cafe | |||
| sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce | sip-1.example.com. 300 IN AAAA 2001:0db8:44:204::d1ce | |||
| sip-1.example.com. 300 IN A 192.0.2.45 | sip-1.example.com. 300 IN A 192.0.2.45 | |||
| sip-1.example.com. 300 IN A 203.0.113.109 | sip-1.example.com. 300 IN A 203.0.113.109 | |||
| sip-1.example.com. 300 IN A 198.51.100.24 | sip-1.example.com. 300 IN A 198.51.100.24 | |||
| skipping to change at page 6, line 47 | skipping to change at page 7, line 5 | |||
| sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead | sip-2.example.com. 300 IN AAAA 2001:0db8:58:c02::dead | |||
| sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef | sip-2.example.com. 300 IN AAAA 2001:0db8:c:a06::2:beef | |||
| sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de | sip-2.example.com. 300 IN AAAA 2001:0db8:44:204::c0de | |||
| sip-2.example.com. 300 IN A 192.0.2.75 | sip-2.example.com. 300 IN A 192.0.2.75 | |||
| sip-2.example.com. 300 IN A 203.0.113.38 | sip-2.example.com. 300 IN A 203.0.113.38 | |||
| sip-2.example.com. 300 IN A 198.51.100.140 | sip-2.example.com. 300 IN A 198.51.100.140 | |||
| Thus, the complete list of destination addresses has this ordering: | Thus, the complete list of destination addresses has this ordering: | |||
| 2001:0db8:58:c02::face 2001:0db8:c:a06::2:cafe | 2001:0db8:58:c02::face | |||
| 2001:0db8:44:204::d1ce 192.0.2.45 203.0.113.109 198.51.100.24 | 2001:0db8:c:a06::2:cafe | |||
| 2001:0db8:58:c02::dead 2001:0db8:c:a06::2:beef | 2001:0db8:44:204::d1ce | |||
| 2001:0db8:44:204::c0de 192.0.2.75 203.0.113.38 198.51.100.140 | 192.0.2.45 | |||
| 203.0.113.109 | ||||
| 198.51.100.24 | ||||
| 2001:0db8:58:c02::dead | ||||
| 2001:0db8:c:a06::2:beef | ||||
| 2001:0db8:44:204::c0de | ||||
| 192.0.2.75 | ||||
| 203.0.113.38 | ||||
| 198.51.100.140 | ||||
| In particular, the destination addresses derived from | In particular, the destination addresses derived from | |||
| sip-1.example.com and those derived from sip-2.example.com are not | sip-1.example.com and those derived from sip-2.example.com are not | |||
| interleaved; [RFC6724] does not operate on the complete list. This | interleaved; [RFC6724] does not operate on the complete list. This | |||
| would be true even if the two SRV records had the same priority and | would be true even if the two SRV records had the same priority and | |||
| were (randomly) ordered based on their weights, as the address | were (randomly) ordered based on their weights, as the address | |||
| records of two target DNS names are never interleaved. | records of two target DNS names are never interleaved. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| skipping to change at page 9, line 4 | skipping to change at page 9, line 14 | |||
| Authors' Addresses | Authors' Addresses | |||
| Olle E. Johansson | Olle E. Johansson | |||
| Edvina AB | Edvina AB | |||
| Runbovaegen 10 | Runbovaegen 10 | |||
| Sollentuna SE-192 48 | Sollentuna SE-192 48 | |||
| Sweden | Sweden | |||
| Email: oej@edvina.net | Email: oej@edvina.net | |||
| Gonzalo Salgueiro | Gonzalo Salgueiro | |||
| Cisco Systems | Cisco Systems | |||
| 7200-12 Kit Creek Road | 7200-12 Kit Creek Road | |||
| Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
| United States of America | United States of America | |||
| Email: gsalguei@cisco.com | Email: gsalguei@cisco.com | |||
| Vijay Gurbani | Vijay K. Gurbani | |||
| Bell Labs, Nokia Networks | Bell Labs, Nokia Networks | |||
| 1960 Lucent Lane | 1960 Lucent Lane | |||
| Rm 9C-533 | Rm 9C-533 | |||
| Naperville, IL 60563 | Naperville, IL 60563 | |||
| United States of America | United States of America | |||
| Email: vkg@bell-labs.com | Email: vkg@bell-labs.com | |||
| Dale R. Worley (editor) | Dale R. Worley (editor) | |||
| Ariadne Internet Services | Ariadne Internet Services | |||
| End of changes. 6 change blocks. | ||||
| 13 lines changed or deleted | 26 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||