1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 6157 Ericsson
Updates: <a href="./rfc3264">3264</a> K. El Malki
Category: Standards Track Athonet
ISSN: 2070-1721 V. Gurbani
Bell Labs, Alcatel-Lucent
April 2011
<span class="h1">IPv6 Transition in the Session Initiation Protocol (SIP)</span>
Abstract
This document describes how the IPv4 Session Initiation Protocol
(SIP) user agents can communicate with IPv6 SIP user agents (and vice
versa) at the signaling layer as well as exchange media once the
session has been successfully set up. Both single- and dual-stack
(i.e., IPv4-only and IPv4/IPv6) user agents are considered.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6157">http://www.rfc-editor.org/info/rfc6157</a>.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Camarillo, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. The Signaling Layer . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1.1">3.1.1</a>. Relaying Requests across Different Networks . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. User Agent Behavior . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. The Media Layer . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Updates to <a href="./rfc3264">RFC 3264</a> . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. Initial Offer . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.3">4.3</a>. Connectivity Checks . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5">5</a>. Contacting Servers: Interaction of <a href="./rfc3263">RFC 3263</a> and <a href="./rfc3484">RFC 3484</a> . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8.1">8.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8.2">8.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. Sample IPv4/IPv6 DNS File . . . . . . . . . . . . . . <a href="#page-14">14</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
SIP [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>] is a protocol to establish and manage multimedia sessions.
After the exchange of signaling messages, SIP endpoints generally
exchange session or media traffic, which is not transported using SIP
but a different protocol. For example, audio streams are typically
carried using the Real-Time Transport Protocol (RTP) [<a href="#ref-13" title=""RTP: A Transport Protocol for Real-Time Applications"">13</a>].
Consequently, a complete solution for IPv6 transition needs to handle
both the signaling layer and the media layer. While unextended SIP
can handle heterogeneous IPv6/IPv4 networks at the signaling layer as
long as proxy servers and their Domain Name System (DNS) entries are
properly configured, user agents using different networks and address
spaces must implement extensions in order to exchange media between
them.
<span class="grey">Camarillo, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
This document addresses the system-level issues in order to make SIP
work successfully between IPv4 and IPv6. Sections <a href="#section-3">3</a> and <a href="#section-4">4</a> provide
discussions on the topics that are pertinent to the signaling layer
and media layer, respectively, to establish a successful session
between heterogeneous IPv4/IPv6 networks.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>] and indicate requirement levels for
compliant implementations.
IPv4-only user agent: An IPv4-only user agent supports SIP signaling
and media only on the IPv4 network. It does not understand IPv6
addresses.
IPv4-only node: A host that implements only IPv4. An IPv4-only node
does not understand IPv6. The installed base of IPv4 hosts
existing before the transition begins are IPv4-only nodes.
IPv6-only user agent: An IPv6-only user agent supports SIP signaling
and media only on the IPv6 network. It does not understand IPv4
addresses.
IPv6-only node: A host that implements IPv6 and does not implement
IPv4.
IPv4/IPv6 node: A host that implements both IPv4 and IPv6; such
hosts are also known as "dual-stack" hosts [<a href="#ref-17" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">17</a>].
IPv4/IPv6 user agent: A user agent that supports SIP signaling and
media on both IPv4 and IPv6 networks.
IPv4/IPv6 proxy: A proxy that supports SIP signaling on both IPv4
and IPv6 networks.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The Signaling Layer</span>
An autonomous domain sends and receives SIP traffic to and from its
user agents as well as to and from other autonomous domains. This
section describes the issues related to such traffic exchanges at the
signaling layer, i.e., the flow of SIP messages between participants
in order to establish the session. We assume that the network
administrators appropriately configure their networks such that the
<span class="grey">Camarillo, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
SIP servers within an autonomous domain can communicate between
themselves. This section contains system-level issues; a companion
document [<a href="#ref-15" title=""Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)"">15</a>] addresses IPv6 parser torture tests in SIP.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Proxy Behavior</span>
User agents typically send SIP traffic to an outbound proxy, which
takes care of routing it forward. In order to support both IPv4-only
and IPv6-only user agents, it is RECOMMENDED that domains deploy
dual-stack outbound proxy servers or, alternatively, deploy both
IPv4-only and IPv6-only outbound proxies. Furthermore, there SHOULD
exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
This allows the user agent to query DNS and obtain an IP address most
appropriate for its use (i.e., an IPv4-only user agent will query DNS
for A resource records (RRs), an IPv6-only user agent will query DNS
for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
and choose a specific network.)
Some domains provide automatic means for user agents to discover
their proxy servers. It is RECOMMENDED that domains implement
appropriate discovery mechanisms to provide user agents with the IPv4
and IPv6 addresses of their outbound proxy servers. For example, a
domain may support both the DHCPv4 [<a href="#ref-11" title=""Dynamic Host Configuration Protocol (DHCP- for-IPv4) Option for Session Initiation Protocol (SIP) Servers"">11</a>] and the DHCPv6 [<a href="#ref-10" title=""Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"">10</a>] options
for SIP servers.
On the receiving side, user agents inside an autonomous domain
receive SIP traffic from sources external to their domain through an
inbound proxy, which is sometimes co-located with the registrar of
the domain. As was the case previously, it is RECOMMENDED that
domains deploy dual-stack inbound proxies or, alternatively, deploy
both IPv4-only and IPv6-only inbound proxy servers. This allows a
user agent external to the autonomous domain to query DNS and receive
an IP address of the inbound proxy most appropriate for its use
(i.e., an IPv4-only user agent will query DNS for A RRs, an IPv6-only
user agent will query DNS for AAAA RRs, and a dual-stack user agent
will query DNS for all RRs and choose a specific network). This
strategy, i.e., deploying dual-stack proxies, also allows for an
IPv6-only user agent in the autonomous domain to communicate with an
IPv4-only user agent in the same autonomous domain. Without such a
proxy, user agents using different networks identifiers will not be
able to successfully signal each other.
Proxies MUST follow the recommendations in <a href="#section-5">Section 5</a> to determine the
order in which to contact the downstream servers when routing a
request.
<span class="grey">Camarillo, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Relaying Requests across Different Networks</span>
A SIP proxy server that receives a request using IPv6 and relays it
to a user agent (or another downstream proxy) using IPv4, and vice
versa, needs to remain in the path traversed by subsequent requests.
Therefore, such a SIP proxy server MUST be configured to Record-Route
in that situation.
Note that while this is the recommended practice, some problems
may still arise if an <a href="./rfc2543">RFC 2543</a> [<a href="#ref-14" title=""SIP: Session Initiation Protocol"">14</a>] endpoint is involved in
signaling. Since the ABNF in <a href="./rfc2543">RFC 2543</a> did not include production
rules to parse IPv6 network identifiers, there is a good chance
that an <a href="./rfc2543">RFC 2543</a>-only compliant endpoint is not able to parse or
regenerate IPv6 network identifiers in headers. Thus, despite a
dual-stack proxy inserting itself into the session establishment,
the endpoint itself may not succeed in the signaling establishment
phase.
This is generally not a problem with <a href="./rfc3261">RFC 3261</a> endpoints; even if
such an endpoint runs on an IPv4-only node, it still is able to
parse and regenerate IPv6 network identifiers.
Relaying a request across different networks in this manner has other
ramifications. For one, the proxy doing the relaying must remain in
the signaling path for the duration of the session; otherwise, the
upstream client and the downstream server would not be able to
communicate directly. Second, to remain in the signaling path, the
proxy MUST insert one or two Record-Route headers: if the proxy is
inserting a URI that contains a Fully Qualified Domain Name (FQDN) of
the proxy, and that name has both IPv4 and IPv6 addresses in DNS,
then inserting one Record-Route header suffices. But if the proxy is
inserting an IP address in the Record-Route header, then it must
insert two such headers; the first Record-Route header contains the
proxy's IP address that is compatible with the network type of the
downstream server, and the second Record-Route header contains the
proxy's IP address that is compatible with the upstream client.
An example helps illustrate this behavior. In the example, we use
only those headers pertinent to the discussion. Other headers have
been omitted for brevity. In addition, only the INVITE request and
final response (200 OK) are shown; it is not the intent of the
example to provide a complete call flow that includes provisional
responses and other requests.
In this example, proxy P, responsible for the domain example.com,
receives a request from an IPv4-only upstream client. It proxies
this request to an IPv6-only downstream server. Proxy P is running
on a dual-stack host; on the IPv4 interface, it has an address of
<span class="grey">Camarillo, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
192.0.2.1, and on the IPv6 interface, it is configured with an
address of 2001:db8::1 (Appendix A contains a sample DNS zone file
entry that has been populated with both IPv4 and IPv6 addresses.)
UAC Proxy UAS
(IPv4) P (IPv6)
| (IPv4/IPv6) |
| | |
+---F1--------->| |
| +---F2-------->|
| | |
| |<--F3---------+
|<--F4----------+ |
... ... ...
| | |
V V V
F1: INVITE sip:alice@example.com SIP/2.0
...
F2: INVITE sip:alice@2001:db8::10 SIP/2.0
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <sip:192.0.2.1;lr>
...
F3: SIP/2.0 200 OK
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <sip:192.0.2.1;lr>
...
F4: SIP/2.0 200 OK
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <sip:192.0.2.1;lr>
...
Figure 1: Relaying requests across different networks
When the User Agent Server (UAS) gets an INVITE and it accepts the
invitation, it sends a 200 OK (F3) and forms a route set. The first
entry in its route set corresponds to the proxy's IPv6 interface.
Similarly, when the 200 OK reaches the User Agent Client (UAC) (F4),
it creates a route set by following the guidelines of <a href="./rfc3261">RFC 3261</a> and
reversing the Record-Route headers. The first entry in its route set
corresponds to the proxy's IPv4 interface. In this manner, both the
UAC and the UAS will have the correct address of the proxy to which
they can target subsequent requests.
<span class="grey">Camarillo, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
Alternatively, the proxy could have inserted its FQDN in the Record-
Route URI and the result would have been the same. This is because
the proxy has both IPv4 and IPv6 addresses in the DNS; thus, the URI
resolution would have yielded an IPv4 address to the UAC and an IPv6
address to the UAS.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. User Agent Behavior</span>
User agent clients MUST follow the normative text specified in
<a href="#section-4.2">Section 4.2</a> to gather IP addresses pertinent to the network. Having
done that, clients MUST follow the recommendations in <a href="#section-5">Section 5</a> to
determine the order of the downstream servers to contact when routing
a request.
Autonomous domains SHOULD deploy dual-stack user agent servers, or
alternatively, deploy both IPv4-only and IPv6-only servers. In
either case, the RR in DNS for reaching the server should be
specified appropriately.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The Media Layer</span>
SIP establishes media sessions using the offer/answer model [<a href="#ref-4" title=""An Offer/Answer Model with the Session Description Protocol (SDP)"">4</a>]. One
endpoint, the offerer, sends a session description (the offer) to the
other endpoint, the answerer. The offer contains all the media
parameters needed to exchange media with the offerer: codecs,
transport addresses, protocols to transfer media, etc.
When the answerer receives an offer, it elaborates an answer and
sends it back to the offerer. The answer contains the media
parameters that the answerer is willing to use for that particular
session. Offer and answer are written using a session description
protocol. The most widespread protocol to describe sessions at
present is called, aptly enough, the Session Description Protocol
(SDP) [<a href="#ref-2" title=""SDP: Session Description Protocol"">2</a>].
A direct offer/answer exchange between an IPv4-only user agent and an
IPv6-only user agent does not result in the establishment of a
session. The IPv6-only user agent wishes to receive media on one or
more IPv6 addresses, but the IPv4-only user agent cannot send media
to these addresses, and generally does not even understand their
format. Consequently, user agents need a means to obtain both IPv4
and IPv6 addresses to receive media and to place them in offers and
answers.
This IP version incompatibility problem would not exist if hosts
implementing IPv6 also implemented IPv4, and were configured with
both IPv4 and IPv6 addresses. In such a case, a UA would be able
<span class="grey">Camarillo, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
to pick a compatible media transport address type to enable the
hosts to communicate with each other.
Pragmatism dictates that IPv6 user agents undertake the greater
burden in the transition period. Since IPv6 user agents are not
widely deployed yet, it seems appropriate that IPv6 user agents
obtain IPv4 addresses instead of mandating an upgrade on the
installed IPv4 base. Furthermore, IPv6 user agents are expected to
be dual-stacked and thus also support IPv4, unlike the larger IPv4-
only user agent base that does not or cannot support IPv6.
An IPv6 node SHOULD also be able to send and receive media using IPv4
addresses, but if it cannot, it SHOULD support Session Traversal
Utilities for NAT (STUN) relay usage [<a href="#ref-8" title=""Traversal Using Relays around NAT (TURN) Extension for IPv6"">8</a>]. Such a relay allows the
IPv6 node to indirectly send and receive media using IPv4.
The advantage of this strategy is that the installed base of IPv4
user agents continues to function unchanged, but it requires an
operator that introduces IPv6 to provide additional servers for
allowing IPv6 user agents to obtain IPv4 addresses. This strategy
may come at an additional cost to SIP operators deploying IPv6.
However, since IPv4-only SIP operators are also likely to deploy STUN
relays for NAT (Network Address Translator) traversal, the additional
effort to deploy IPv6 in an IPv4 SIP network should be limited in
this aspect.
However, there will be deployments where an IPv4/IPv6 node is unable
to use both interfaces natively at the same time, and instead, runs
as an IPv6-only node. Examples of such deployments include:
1. Networks where public IPv4 addresses are scarce and it is
preferable to make large deployments only on IPv6.
2. Networks utilizing Layer-2's that do not support concurrent IPv4
and IPv6 usage on the same link.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Updates to <a href="./rfc3264">RFC 3264</a></span>
This section provides a normative update to <a href="./rfc3264">RFC 3264</a> [<a href="#ref-4" title=""An Offer/Answer Model with the Session Description Protocol (SDP)"">4</a>] in the
following manner:
1. In some cases, especially those dealing with third party call
control (see Section 4.2 of [<a href="#ref-12" title=""Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)"">12</a>]), there arises a need to specify
the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
the SDP offer. For this, IPv6 implementations MUST use a domain
name within the .invalid DNS top-level domain instead of using
the IPv6 unspecified address (i.e., ::).
<span class="grey">Camarillo, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
2. Each media description in the SDP answer MUST use the same
network type as the corresponding media description in the offer.
Thus, if the applicable "c=" line for a media description in the
offer contained a network type with the value "IP4", the
applicable "c=" line for the corresponding media description in
the answer MUST contain "IP4" as the network type. Similarly, if
the applicable "c=" line for a media description in the offer
contained a network type with the value "IP6", the applicable
"c=" line for the corresponding media description in the answer
MUST contain "IP6" as the network type.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Initial Offer</span>
We now describe how user agents can gather addresses by following the
Interactive Connectivity Establishment (ICE) [<a href="#ref-7" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">7</a>] procedures. ICE is
protocol that allows two communicating user agents to arrive at a
pair of mutually reachable transport addresses for media
communications in the presence of NATs. It uses the STUN [<a href="#ref-18" title=""Session Traversal Utilities for NAT (STUN)"">18</a>]
protocol, applying its binding discovery and relay usages.
When following the ICE procedures, in addition to local addresses,
user agents may need to obtain addresses from relays; for example, an
IPv6 user agent would obtain an IPv4 address from a relay. The relay
would forward the traffic received on this IPv4 address to the user
agent using IPv6. Such user agents MAY use any mechanism to obtain
addresses in relays, but, following the recommendations in ICE, it is
RECOMMENDED that user agents support STUN relay usage [<a href="#ref-6" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">6</a>] [<a href="#ref-8" title=""Traversal Using Relays around NAT (TURN) Extension for IPv6"">8</a>] for
this purpose.
IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
using the ICE procedures to generate all their offers. This way,
both IPv4-only and IPv6-only answerers will be able to generate a
mutually acceptable answer that establishes a session (having used
ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
session establishment time because all answerers will find the offer
valid.)
Implementations are encouraged to use ICE; however, the normative
strength of the text above is left at a SHOULD since in some
managed networks (such as a closed enterprise network) it is
possible for the administrator to have control over the IP version
utilized in all nodes and thus deploy an IPv6-only network, for
example. The use of ICE can be avoided for signaling messages
that stay within such managed networks.
<span class="grey">Camarillo, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Connectivity Checks</span>
Once the answerer has generated an answer following the ICE
procedures, both user agents perform the connectivity checks as
specified by ICE. These checks help prevent some types of flooding
attacks and allow user agents to discover new addresses that can be
useful in the presence of NATs.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Contacting Servers: Interaction of <a href="./rfc3263">RFC 3263</a> and <a href="./rfc3484">RFC 3484</a></span>
<a href="./rfc3263">RFC 3263</a> maps a SIP or SIPS URI to a set of DNS SRV records for the
various servers that can handle the URI. The Expected Output, given
an Application Unique String (the URI) is one or more SRV records,
sorted by the "priority" field, and further ordered by the "weight"
field in each priority class.
The terms "Expected Output" and "Application Unique String", as
they are to be interpreted in the context of SIP, are defined in
<a href="./rfc3263#section-8">Section 8 of RFC 3263</a> [<a href="#ref-5" title=""Session Initiation Protocol (SIP): Locating SIP Servers"">5</a>].
To find a particular IP address to send the request to, the client
will eventually perform an A or AAAA DNS lookup on a target. As
specified in <a href="./rfc3263">RFC 3263</a>, this target will have been obtained through
NAPTR and SRV lookups, or if NAPTR and SRV lookup did not return any
records, the target will simply be the domain name of the Application
Unique String. In order to translate the target to the corresponding
set of IP addresses, IPv6-only or dual-stack clients MUST use the
newer getaddrinfo() name lookup function, instead of gethostbyname()
[<a href="#ref-16" title=""Application Aspects of IPv6 Transition"">16</a>]. The new function implements the Source and Destination Address
Selection algorithms specified in <a href="./rfc3484">RFC 3484</a> [<a href="#ref-9" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">9</a>], which is expected to
be supported by all IPv6 hosts.
The advantage of the additional complexity is that this technique
will output an ordered list of IPv6/IPv4 destination addresses based
on the relative merits of the corresponding source/destination pairs.
This will guarantee optimal routing. However, the Source and
Destination Selection algorithms of <a href="./rfc3484">RFC3484</a> are dependent on broad
operating system support and uniform implementation of the
application programming interfaces that implement this behavior.
Developers should carefully consider the issues described by Roy
et al. [<a href="#ref-19" title=""IPv6 Neighbor Discovery On- Link Assumption Considered Harmful"">19</a>] with respect to address resolution delays and address
selection rules. For example, implementations of getaddrinfo()
may return address lists containing IPv6 global addresses at the
top of the list and IPv4 addresses at the bottom, even when the
host is only configured with an IPv6 local scope (e.g., link-
local) and an IPv4 address. This will, of course, introduce a
delay in completing the connection.
<span class="grey">Camarillo, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This document describes how IPv4 SIP user agents can communicate with
IPv6 user agents (and vice versa). To do this, it uses additional
protocols (STUN relay usage [<a href="#ref-6" title=""Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)"">6</a>], ICE [<a href="#ref-7" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">7</a>], SDP [<a href="#ref-2" title=""SDP: Session Description Protocol"">2</a>]); the threat model
of each such protocol is included in its respective document. The
procedures introduced in this document do not introduce the
possibility of any new security threats; however, they may make hosts
more amenable to existing threats. Consider, for instance, a UAC
that allocates an IPv4 and an IPv6 address locally and inserts these
into the SDP. Malicious user agents that may intercept the request
can mount a denial-of-service attack targeted to the different
network interfaces of the UAC. In such a case, the UAC should use
mechanisms that protect confidentiality and integrity of the
messages, such as using the SIPS URI scheme as described in <a href="./rfc3261#section-26.2.2">Section</a>
<a href="./rfc3261#section-26.2.2">26.2.2 of RFC3261</a> [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>], or secure MIME as described in <a href="./rfc3261#section-23">Section 23 of
RFC3261</a> [<a href="#ref-3" title=""SIP: Session Initiation Protocol"">3</a>]. If HTTP Digest is used as an authentication mechanism
in SIP, then the UAC should ensure that the quality of protection
also includes the SDP payload.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
The authors would like to thank Mohamed Boucadair, Christine Fischer,
Cullen Jennings, Aki Niemi, Jonathan Rosenberg, and Robert Sparks for
discussions on the working group list that improved the quality of
this document.
Additionally, Francois Audet, Mary Barnes, Keith Drage, and Dale
Worley provided invaluable comments as part of the working group Last
Call review process. Jari Arkko, Lars Eggert, Tobias Gondrom, Suresh
Krishnan, and Tim Polk conducted an in-depth review of the work as
part of the IESG and Gen-ART reviews.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-3">3</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.
<span class="grey">Camarillo, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
[<a id="ref-4">4</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", <a href="./rfc3264">RFC 3264</a>, June 2002.
[<a id="ref-5">5</a>] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", <a href="./rfc3263">RFC 3263</a>, June 2002.
[<a id="ref-6">6</a>] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Traversal
Utilities for NAT (STUN)", <a href="./rfc5766">RFC 5766</a>, April 2010.
[<a id="ref-7">7</a>] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", <a href="./rfc5245">RFC 5245</a>, April 2010.
[<a id="ref-8">8</a>] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using
Relays around NAT (TURN) Extension for IPv6", <a href="./rfc6156">RFC 6156</a>, April
2011.
[<a id="ref-9">9</a>] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>, February 2003.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-10">10</a>] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", <a href="./rfc3319">RFC 3319</a>, July 2003.
[<a id="ref-11">11</a>] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
for-IPv4) Option for Session Initiation Protocol (SIP)
Servers", <a href="./rfc3361">RFC 3361</a>, August 2002.
[<a id="ref-12">12</a>] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", <a href="https://www.rfc-editor.org/bcp/bcp85">BCP 85</a>, <a href="./rfc3725">RFC 3725</a>,
April 2004.
[<a id="ref-13">13</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
<a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-14">14</a>] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", <a href="./rfc2543">RFC 2543</a>, March 1999.
[<a id="ref-15">15</a>] Gurbani, V., Boulton, C., and R. Sparks, "Session Initiation
Protocol (SIP) Torture Test Messages for Internet Protocol
Version 6 (IPv6)", <a href="./rfc5118">RFC 5118</a>, February 2008.
<span class="grey">Camarillo, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
[<a id="ref-16">16</a>] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro,
"Application Aspects of IPv6 Transition", <a href="./rfc4038">RFC 4038</a>, March 2005.
[<a id="ref-17">17</a>] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>, October 2005.
[<a id="ref-18">18</a>] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
Traversal Utilities for NAT (STUN)", <a href="./rfc5389">RFC 5389</a>, October 2008.
[<a id="ref-19">19</a>] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-
Link Assumption Considered Harmful", <a href="./rfc4943">RFC 4943</a>, September 2007.
<span class="grey">Camarillo, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Sample IPv4/IPv6 DNS File</span>
A portion of a sample DNS zone file entry is reproduced below that
has both IPv4 and IPv6 addresses. This entry corresponds to a proxy
server for the domain "example.com". The proxy server supports the
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
transport for both IPv4 and IPv6 networks.
...
_sip._tcp SRV 20 0 5060 sip1.example.com
SRV 0 0 5060 sip2.example.com
_sip._udp SRV 20 0 5060 sip1.example.com
SRV 0 0 5060 sip2.example.com
sip1 IN A 192.0.2.1
sip1 IN AAAA 2001:db8::1
sip2 IN A 192.0.2.2
sip2 IN AAAA 2001:db8::2
...
<span class="grey">Camarillo, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6157">RFC 6157</a> IPv6 Transition in SIP April 2011</span>
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Karim El Malki
Athonet
AREA Science Park
Padriciano 99
Trieste (TS) 34149
Italy
EMail: karim@athonet.com
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Rm 9C-533
Naperville, IL 60563
USA
Phone: +1 630 224 0216
EMail: vkg@bell-labs.com
Camarillo, et al. Standards Track [Page 15]
</pre>
|
