-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-ietf-tsvwg-natsupp.xml
2104 lines (1930 loc) · 92.6 KB
/
draft-ietf-tsvwg-natsupp.xml
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
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc='yes'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
xml:lang="en"
ipr="trust200902"
submissionType="IETF"
consensus="true"
category="std"
docName="draft-ietf-tsvwg-natsupp-23-to-be"
version="3">
<front>
<title abbrev='SCTP NAT Support'>
Stream Control Transmission Protocol (SCTP) Network Address Translation Support
</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-natsupp-23-to-be"/>
<!-- ************** RANDALL STEWART ***************-->
<author initials='R. R.' surname='Stewart' fullname='Randall R. Stewart'>
<organization>Netflix, Inc.</organization>
<address>
<postal>
<street></street>
<city>Chapin</city> <region>SC</region>
<code>29036</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<!-- ************** MICHAEL TUEXEN *************** -->
<author initials='M.' surname='Tüxen' fullname='Michael Tüxen'>
<organization abbrev='Münster Univ. of Appl. Sciences'>
Münster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<city>48565 Steinfurt</city>
<country>DE</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<!-- *************** IRENE RUENGELER ***************** -->
<author initials='I.' surname='Rüngeler' fullname='Irene Rüngeler'>
<organization abbrev='Münster Univ. of Appl. Sciences'>
Münster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<city>48565 Steinfurt</city>
<country>DE</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date/>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The Stream Control Transmission Protocol (SCTP) provides a reliable
communications channel between two end-hosts in many ways similar to the
Transmission Control Protocol (TCP).
With the widespread deployment of Network Address Translators (NAT),
specialized code has been added to NAT functions for TCP that allows multiple
hosts to reside behind a NAT function and yet share a single IPv4 address,
even when two hosts (behind a NAT function) choose the same port numbers for
their connection.
This additional code is sometimes classified as Network Address and Port
Translation (NAPT).</t>
<t>This document describes the protocol extensions needed for the SCTP
endpoints and the mechanisms for NAT functions necessary to provide similar
features of NAPT in the single point and multipoint traversal scenario.</t>
<t>Finally, a YANG module for SCTP NAT is defined.</t>
</abstract>
</front>
<middle>
<section>
<name>Introduction</name>
<t>Stream Control Transmission Protocol (SCTP) <xref target='RFC4960'/>
provides a reliable communications channel between two end-hosts in many
ways similar to TCP <xref target='RFC0793'/>. With the widespread
deployment of Network Address Translators (NAT), specialized code has been
added to NAT functions for TCP that allows multiple hosts to reside behind a NAT
function using private-use addresses (see <xref target='RFC6890'/>) and yet share
a single IPv4 address, even when two hosts (behind a NAT function) choose the
same port numbers for their connection.
This additional code is sometimes classified as Network Address and Port
Translation (NAPT).
Please note that this document focuses on the case where the NAT function maps a
single or multiple internal addresses to a single external address and vice versa.</t>
<t>To date, specialized code for SCTP has not yet been
added to most NAT functions so that only a translation of IP addresses is
supported.
The end result of this is that only one SCTP-capable host can successfully
operate behind such a NAT function and this host can only be single-homed.
The only alternative for supporting legacy NAT functions is to use
UDP encapsulation as specified in <xref target='RFC6951'/>.</t>
<t>The NAT function in the document refers to NAPT functions described in
Section 2.2 of <xref target='RFC3022'/>, NAT64 <xref target='RFC6146'/>,
or DS-Lite AFTR <xref target='RFC6333'/>.</t>
<t>This document specifies procedures allowing a NAT function to support SCTP
by providing similar features to those provided by a NAPT for
TCP (see <xref target='RFC5382'/> and <xref target='RFC7857'/>),
UDP (see <xref target='RFC4787'/> and <xref target='RFC7857'/>),
and ICMP (see <xref target='RFC5508'/> and <xref target='RFC7857'/>).
This document also specifies a set of data formats for SCTP packets and a set
of SCTP endpoint procedures to support NAT traversal.
An SCTP implementation supporting these procedures can assure that in both
single-homed and multi-homed cases a NAT function will maintain the appropriate
state without the NAT function needing to change port numbers.</t>
<t>It is possible and desirable to make these changes for a number of
reasons:</t>
<ul>
<li>It is desirable for SCTP internal end-hosts on multiple platforms to be able
to share a NAT function's external IP address in the same way that a TCP session
can use a NAT function.</li>
<li><t>If a NAT function does not need to change any data within an SCTP packet,
it will reduce the processing burden of NAT'ing SCTP by not needing to execute
the CRC32c checksum used by SCTP.</t></li>
<li><t>Not having to touch the IP payload makes the processing of ICMP
messages by NAT functions easier.</t></li>
</ul>
<t>An SCTP-aware NAT function will need to follow these procedures for generating
appropriate SCTP packet formats.</t>
<t>When considering SCTP-aware NAT it is possible to have
multiple levels of support. At each level, the Internal
Host, Remote Host, and NAT function does or does not support the
procedures described in this document. The following table
illustrates the results of the various combinations of
support and if communications can occur between two endpoints.</t>
<table anchor="communication_table" align="center">
<name>Communication possibilities</name>
<thead>
<tr><th align="center">Internal Host</th> <th align="center">NAT Function</th> <th align="center">Remote Host</th> <th align="center">Communication</th></tr>
</thead>
<tbody>
<tr><td align="center">Support </td> <td align="center">Support </td> <td align="center">Support </td> <td align="center">Yes </td></tr>
<tr><td align="center">Support </td> <td align="center">Support </td> <td align="center">No Support </td> <td align="center">Limited </td></tr>
<tr><td align="center">Support </td> <td align="center">No Support</td> <td align="center">Support </td> <td align="center">None </td></tr>
<tr><td align="center">Support </td> <td align="center">No Support</td> <td align="center">No Support </td> <td align="center">None </td></tr>
<tr><td align="center">No Support </td> <td align="center">Support </td> <td align="center">Support </td> <td align="center">Limited </td></tr>
<tr><td align="center">No Support </td> <td align="center">Support </td> <td align="center">No Support </td> <td align="center">Limited </td></tr>
<tr><td align="center">No Support </td> <td align="center">No Support</td> <td align="center">Support </td> <td align="center">None </td></tr>
<tr><td align="center">No Support </td> <td align="center">No Support</td> <td align="center">No Support </td> <td align="center">None </td></tr>
</tbody>
</table>
<t>From the table it can be seen that no communication can occur when a
NAT function does not support SCTP-aware NAT.
This assumes that the NAT function does not handle SCTP packets at all and
all SCTP packets sent from behind a NAT function are discarded by
the NAT function.
In some cases, where the NAT function supports SCTP-aware NAT, but one of the
two hosts does not support the feature, communication can possibly occur in a
limited way.
For example, only one host can have a connection when a collision case occurs.</t>
</section>
<section anchor='conventions'>
<name>Conventions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor='terminology'>
<name>Terminology</name>
<t>This document uses the following terms, which are depicted in
<xref target='terminology_fig'/>. Familiarity with the terminology used in
<xref target='RFC4960'/> and <xref target='RFC5061'/> is assumed.</t>
<dl newline="true">
<dt>Internal-Address (Int-Addr)</dt>
<dd><t>An internal address that is known to the internal host.</t></dd>
<dt>Internal-Port (Int-Port)</dt>
<dd><t>The port number that is in use by the host holding the
Internal-Address.</t></dd>
<dt>Internal-VTag (Int-VTag)</dt>
<dd><t>The SCTP Verification Tag (VTag) (see Section 3.1 of
<xref target='RFC4960'/>) that the internal host has chosen for an
association.
The VTag is a unique 32-bit tag that accompanies any incoming SCTP packet
for this association to the Internal-Address.</t></dd>
<dt>Remote-Address (Rem-Addr)</dt>
<dd><t>The address that an internal host is attempting to contact.</t></dd>
<dt>Remote-Port (Rem-Port)</dt>
<dd><t>The port number used by the host holding the Remote-Address.</t></dd>
<dt>Remote-VTag (Rem-VTag)</dt>
<dd><t>The Verification Tag (VTag) (see Section 3.1 of <xref target='RFC4960'/>)
that the host holding the Remote-Address has chosen for an association.
The VTag is a unique 32-bit tag that accompanies any outgoing
SCTP packet for this association to the Remote-Address.</t></dd>
<dt>External-Address (Ext-Addr)</dt>
<dd><t>An external address assigned to the NAT function, that it uses as a source
address when sending packets towards a Remote-Address.</t></dd>
</dl>
<figure anchor='terminology_fig'>
<name>Basic Network Setup</name>
<artwork align="center">
Internal Network | External Network
|
Internal | External Remote
Address | Address /--\/--\ Address
+--------+ +-----+ / \ +--------+
| Host A |=========| NAT |=======| Network |==========| Host B |
+--------+ +-----+ \ / +--------+
Internal | \--/\--/ Remote
Internal Port | Port Remote
VTag | VTag
</artwork>
</figure>
</section>
<section>
<name>Motivation and Overview</name>
<section>
<name>SCTP NAT Traversal Scenarios</name>
<t>This section defines the notion of single and
multipoint NAT traversal. </t>
<section anchor='single_point_traversal'>
<name>Single Point Traversal</name>
<t>In this case, all packets in the SCTP association go through a
single NAT function, as shown in <xref target='single_nat_scenario_fig'/>.</t>
<figure anchor='single_nat_scenario_fig'>
<name>Single NAT Function Scenario</name>
<artwork align="center">
Internal Network | External Network
|
| /--\/--\
+--------+ +-----+ / \ +--------+
| Host A |=========| NAT |========= | Network | ========| Host B |
+--------+ +-----+ \ / +--------+
| \--/\--/
|
</artwork>
</figure>
<t>A variation of this case is shown in <xref target='serial_nat_szenario_fig'/>,
i.e., multiple NAT functions in the forwarding path between two endpoints.</t>
<figure anchor='serial_nat_szenario_fig'>
<name>Serial NAT Functions Scenario</name>
<artwork align="center">
Internal | External : Internal | External
| : |
| : | /--\/--\
+--------+ +-----+ : +-----+ / \ +--------+
| Host A |==| NAT |=======:=======| NAT |==| Network |==| Host B |
+--------+ +-----+ : +-----+ \ / +--------+
| : | \--/\--/
| : |
</artwork>
</figure>
<t>Although one of the main benefits of SCTP multi-homing is redundant
paths, in the single point traversal scenario the NAT function represents
a single point of failure in the path of the SCTP multi-homed association.
However, the rest of the path can still benefit from path diversity provided
by SCTP multi-homing.</t>
<t>The two SCTP endpoints in this case can be either single-homed or
multi-homed. However, the important thing is that the NAT function
in this case sees all the packets of the SCTP association.</t>
</section>
<section>
<name>Multipoint Traversal</name>
<t>This case involves multiple NAT functions and each NAT function only sees some
of the packets in the SCTP association.
An example is shown in <xref target='parallel_nat_scenario_fig'/>.</t>
<figure anchor='parallel_nat_scenario_fig'>
<name>Parallel NAT Functions Scenario</name>
<artwork align="center">
Internal | External
+------+ /---\/---\
/=======|NAT A |=========\ / \
+--------+ / +------+ \/ \ +--------+
| Host A |/ | | Network |===| Host B |
+--------+\ | \ / +--------+
\ +------+ / \ /
\=======|NAT B |=========/ \---\/---/
+------+
|
</artwork>
</figure>
<t>This case does not apply to a single-homed SCTP association (i.e.,
both endpoints in the association use only one IP address). The
advantage here is that the existence of multiple NAT traversal points
can preserve the path diversity of a multi-homed association for the
entire path. This in turn can improve the robustness of the
communication.</t>
</section>
</section>
<section>
<name>Limitations of Classical NAPT for SCTP</name>
<t>Using classical NAPT possibly results in changing one of the SCTP port numbers
during the processing, which requires the recomputation of the transport layer
checksum by the NAPT function.
Whereas for UDP and TCP this can be done very efficiently, for SCTP
the checksum (CRC32c) over the entire packet needs to be recomputed
(see Appendix B of <xref target='RFC4960'/> for details of the CRC32c
computation).
This would considerably add to the NAT computational burden, however hardware
support can mitigate this in some implementations.</t>
<t>An SCTP endpoint can have multiple addresses but only has a single port
number to use.
To make multipoint traversal work, all the NAT functions involved need to
recognize the packets they see as belonging to the same SCTP association and
perform port number translation in a consistent way.
One possible way of doing this is to use a pre-defined table of port numbers
and addresses configured within each NAT function.
Other mechanisms could make use of NAT to NAT communication.
Such mechanisms have not been deployed on a wide scale base and thus are not
a preferred solution.
Therefore an SCTP variant of NAT function has been developed
(see <xref target='SCTP_aware_NAT'/>).</t>
</section>
<section anchor='SCTP_aware_NAT'>
<name>The SCTP-Specific Variant of NAT</name>
<t>In this section it is allowed that there are multiple SCTP capable hosts
behind a NAT function that share one External-Address.
Furthermore, this section focuses on the single point traversal scenario
(see <xref target='single_point_traversal'/>).</t>
<t>The modification of outgoing SCTP packets sent from an internal host is
simple: the source address of the packets has to be replaced with the
External-Address. It might also be necessary to establish some
state in the NAT function to later handle incoming packets.</t>
<t>Typically, the NAT function has to maintain a NAT binding table
of Internal-VTag, Internal-Port, Remote-VTag, Remote-Port, Internal-Address,
and whether the restart procedure is disabled or not.
An entry in that NAT binding table is called a NAT-State control block.
The function Create() obtains the just mentioned parameters and returns
a NAT-State control block.
A NAT function MAY allow creating NAT-State control blocks via a management
interface.</t>
<t>For SCTP packets coming from the external realm of the NAT function the
destination address of the packets has to be replaced with the Internal-Address
of the host to which the packet has to be delivered, if a NAT state entry is
found.
The lookup of the Internal-Address is based on the Remote-VTag, Remote-Port,
Internal-VTag and the Internal-Port.</t>
<t>The entries in the NAT binding table need to fulfill some uniqueness
conditions.
There can not be more than one entry NAT binding table with the same pair of
Internal-Port and Remote-Port.
This rule can be relaxed, if all NAT binding table entries with the same
Internal-Port and Remote-Port have the support for the restart
procedure disabled (see <xref target='disrestart'/>).
In this case there can not be no more than one entry with the same Internal-Port,
Remote-Port and Remote-VTag and no more than one NAT binding table entry with
the same Internal-Port, Remote-Port, and Int-VTag.</t>
<t>The processing of outgoing SCTP packets containing an INIT chunk
is illustrated in the following figure. This scenario is valid for all
message flows in this section.</t>
<artwork align="center">
<![CDATA[
/--\/--\
+--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+
\--/\---/
INIT[Initiate-Tag]
Int-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag=0
Create(Initiate-Tag, Int-Port, 0, Rem-Port, Int-Addr,
IsRestartDisabled)
Returns(NAT-State control block)
Translate To:
INIT[Initiate-Tag]
Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag=0
]]>
</artwork>
<t>Normally a NAT binding table entry will be created.</t>
<t>However, it is possible that there is already a NAT binding table entry with
the same Remote-Port, Internal-Port, and Internal-VTag
but different Internal-Address and the restart procedure is disabled.
In this case the packet containing the INIT chunk MUST be dropped by the NAT
and a packet containing an ABORT chunk SHOULD be sent to the SCTP host that
originated the packet with the M bit set and 'VTag and Port Number Collision'
error cause (see <xref target='mbitabort'/> for the format).
The source address of the packet containing the ABORT chunk MUST be the
destination address of the packet containing the INIT chunk.</t>
<t>If an outgoing SCTP packet contains an INIT or ASCONF chunk and a matching
NAT binding table entry is found, the packet is processed as a normal
outgoing packet.</t>
<t>It is also possible that a NAT binding table entry with the same Remote-Port
and Internal-Port exists without an Internal-VTag conflict but there exists
a NAT binding table entry with the same port numbers but a different
Internal-Address and the restart procedure is not disabled.
In such a case the packet containing the INIT chunk MUST be dropped by the NAT function
and a packet containing an ABORT chunk SHOULD be sent to the SCTP host that
originated the packet with the M bit set and 'Port Number Collision' error
cause (see <xref target='mbitabort'/> for the format).</t>
<t>The processing of outgoing SCTP packets containing no INIT chunks
is described in the following figure.</t>
<artwork align="center">
<![CDATA[
/--\/--\
+--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+
\--/\---/
Int-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag
Translate To:
Ext-Addr:Int-Port ------> Rem-Addr:Rem-Port
Rem-VTag
]]>
</artwork>
<t>The processing of incoming SCTP packets containing an INIT ACK chunk
is illustrated in the following figure.
The Lookup() function has as input the Internal-VTag, Internal-Port,
Remote-VTag, and Remote-Port.
It returns the corresponding entry of the NAT binding table and updates
the Remote-VTag by substituting it with the value of the Initiate-Tag of the
INIT ACK chunk.
The wildcard character signifies that the parameter's value is not considered
in the Lookup() function or changed in the Update() function, respectively.</t>
<artwork align="center">
<![CDATA[
/--\/--\
+--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+
\--/\---/
INIT ACK[Initiate-Tag]
Ext-Addr:Int-Port <---- Rem-Addr:Rem-Port
Int-VTag
Lookup(Int-VTag, Int-Port, *, Rem-Port)
Update(*, *, Initiate-Tag, *)
Returns(NAT-State control block containing Int-Addr)
INIT ACK[Initiate-Tag]
Int-Addr:Int-Port <------ Rem-Addr:Rem-Port
Int-VTag
]]>
</artwork>
<t>In the case where the Lookup function fails because it does not find an
entry, the SCTP packet is dropped.
If it succeeds, the Update routine inserts the Remote-VTag
(the Initiate-Tag of the INIT ACK chunk) in the NAT-State control block.</t>
<t>The processing of incoming SCTP packets containing an ABORT or
SHUTDOWN COMPLETE chunk with the T bit set is illustrated in the
following figure.</t>
<artwork align="center">
<![CDATA[
/--\/--\
+--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+
\--/\---/
Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port
Rem-VTag
Lookup(*, Int-Port, Rem-VTag, Rem-Port)
Returns(NAT-State control block containing Int-Addr)
Int-Addr:Int-Port <------ Rem-Addr:Rem-Port
Rem-VTag
]]>
</artwork>
<t>For an incoming packet containing an INIT chunk a table lookup is made
only based on the addresses and port numbers.
If an entry with a Remote-VTag of zero is found, it is considered a
match and the Remote-VTag is updated.
If an entry with a non-matching Remote-VTag is found or no entry is found,
the incoming packet is silently dropped. If an entry with a matching Remote-VTag
is found, the incoming packet is forwarded.
This allows the handling of INIT collision through NAT functions.</t>
<t>The processing of other incoming SCTP packets is described in the
following figure.</t>
<artwork align="center">
<![CDATA[
/--\/--\
+--------+ +-----+ / \ +--------+
| Host A | <------> | NAT | <------> | Network | <------> | Host B |
+--------+ +-----+ \ / +--------+
\--/\---/
Ext-Addr:Int-Port <------ Rem-Addr:Rem-Port
Int-VTag
Lookup(Int-VTag, Int-Port, *, Rem-Port)
Returns(NAT-State control block containing Internal-Address)
Int-Addr:Int-Port <------ Rem-Addr:Rem-Port
Int-VTag
]]>
</artwork>
</section>
</section>
<section>
<name>Data Formats</name>
<t>This section defines the formats used to support NAT traversal.
<xref target='chunks'/> and <xref target='errcause'/> describe chunks
and error causes sent by NAT functions and received by SCTP endpoints.
<xref target='newparam'/> describes parameters sent by SCTP endpoints and
used by NAT functions and SCTP endpoints.</t>
<section anchor='chunks'>
<name>Modified Chunks</name>
<t>This section presents existing chunks defined in <xref target='RFC4960'/>
for which additional flags are specified by this document.</t>
<section anchor='mbitabort'>
<name>Extended ABORT Chunk</name>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Reserved |M|T| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ zero or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<t>The ABORT chunk is extended to add the new 'M bit'. The M bit
indicates to the receiver of the ABORT chunk that the chunk was not
generated by the peer SCTP endpoint, but instead by a middle box (e.g., NAT).</t>
<t>[NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.]</t>
</section>
<section anchor='mbiterr'>
<name>Extended ERROR Chunk</name>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Reserved |M|T| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ zero or more Error Causes /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<t>The ERROR chunk defined in <xref target='RFC4960'/> is extended to
add the new 'M bit'. The M bit indicates to the receiver of the ERROR chunk
that the chunk was not generated by the peer SCTP endpoint, but instead
by a middle box.</t>
<t>[NOTE to RFC-Editor: Assignment of M bit to be confirmed by IANA.]</t>
</section>
</section>
<section anchor='errcause'>
<name>New Error Causes</name>
<t>This section defines the new error causes added by this document.</t>
<section anchor='port_coll'>
<name>VTag and Port Number Collision Error Cause</name>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 0x00B0 | Cause Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Chunk /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Cause Code: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the IANA defined cause code for the
'VTag and Port Number Collision' Error Cause.
IANA is requested to assign the value 0x00B0 for this cause code.</t></dd>
<dt>Cause Length: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the length in bytes of the error cause.
The value MUST be the length of the Cause-Specific Information plus 4.</t></dd>
<dt>Chunk: variable length</dt>
<dd><t>The Cause-Specific Information is filled with the chunk that caused this
error.
This can be an INIT, INIT ACK, or ASCONF chunk.
Note that if the entire chunk will not fit in the ERROR chunk or ABORT chunk
being sent then the bytes that do not fit are truncated.</t></dd>
</dl>
<t>[NOTE to RFC-Editor: Assignment of cause code to be confirmed by IANA.]</t>
</section>
<section anchor='miss_state'>
<name>Missing State Error Cause</name>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 0x00B1 | Cause Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Original Packet /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Cause Code: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the IANA defined cause code for the
'Missing State' Error Cause.
IANA is requested to assign the value 0x00B1 for this cause code.</t></dd>
<dt>Cause Length: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the length in bytes of the error cause.
The value MUST be the length of the Cause-Specific Information plus 4.</t></dd>
<dt>Original Packet: variable length</dt>
<dd><t>The Cause-Specific Information is filled with the IPv4 or IPv6 packet that
caused this error. The IPv4 or IPv6 header MUST be included.
Note that if the packet will not fit in the ERROR chunk or ABORT chunk
being sent then the bytes that do not fit are truncated.</t></dd>
</dl>
<t>[NOTE to RFC-Editor: Assignment of cause code to be confirmed by IANA.]</t>
</section>
<section anchor='portcollide'>
<name>Port Number Collision Error Cause</name>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code = 0x00B2 | Cause Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Chunk /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Cause Code: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the IANA defined cause code for the
'Port Number Collision' Error Cause.
IANA is requested to assign the value 0x00B2 for this cause code.</t></dd>
<dt>Cause Length: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the length in bytes of the error cause.
The value MUST be the length of the Cause-Specific Information plus 4.</t></dd>
<dt>Chunk: variable length</dt>
<dd><t>The Cause-Specific Information is filled with the chunk that caused this
error.
This can be an INIT, INIT ACK, or ASCONF chunk.
Note that if the entire chunk will not fit in the ERROR chunk or ABORT chunk
being sent then the bytes that do not fit are truncated.</t></dd>
</dl>
<t>[NOTE to RFC-Editor: Assignment of cause code to be confirmed by IANA.]</t>
</section>
</section>
<section anchor='newparam'>
<name>New Parameters</name>
<t>This section defines new parameters and their valid appearance
defined by this document.</t>
<section anchor='disrestart'>
<name>Disable Restart Parameter</name>
<t>This parameter is used to indicate that the restart procedure
is requested to be disabled. Both endpoints of an association MUST
include this parameter in the INIT chunk and INIT ACK chunk when
establishing an association and MUST include it in the ASCONF chunk
when adding an address to successfully disable the restart procedure.</t>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC007 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Parameter Type: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the IANA defined parameter type for the Disable Restart Parameter.
IANA is requested to assign the value 0xC007 for this parameter type.</t></dd>
<dt>Parameter Length: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the length in bytes of the parameter.
The value MUST be 4.</t></dd>
</dl>
<t>[NOTE to RFC-Editor: Assignment of parameter type to be confirmed by IANA.]</t>
<t>The Disable Restart Parameter MAY appear in INIT, INIT ACK and ASCONF chunks
and MUST NOT appear in any other chunk.</t>
</section>
<section anchor='vtags-parameter'>
<name>VTags Parameter</name>
<t>This parameter is used to help a NAT function to recover from state loss.</t>
<artwork align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0xC008 | Parameter Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Verification Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<dl newline="true">
<dt>Parameter Type: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the IANA defined parameter type for the VTags Parameter.
IANA is requested to assign the value 0xC008 for this parameter type.</t></dd>
<dt>Parameter Length: 2 bytes (unsigned integer)</dt>
<dd><t>This field holds the length in bytes of the parameter.
The value MUST be 16.</t></dd>
<dt>ASCONF-Request Correlation ID: 4 bytes (unsigned integer)</dt>
<dd><t>This is an opaque integer assigned by the sender to identify each
request parameter. The receiver of the ASCONF Chunk will copy this
32-bit value into the ASCONF Response Correlation ID field of the
ASCONF ACK response parameter. The sender of the packet containing the ASCONF
chunk can use this same value in the ASCONF ACK chunk to find which request the
response is for. The receiver MUST NOT change the value of the ASCONF-Request
Correlation ID.</t></dd>
<dt>Internal Verification Tag: 4 bytes (unsigned integer)</dt>
<dd><t>The Verification Tag that the internal host has chosen for the association.
The Verification Tag is a unique 32-bit tag that accompanies
any incoming SCTP packet for this association to the Internal-Address.</t></dd>
<dt>Remote Verification Tag: 4 bytes (unsigned integer)</dt>
<dd><t>The Verification Tag that the host holding the Remote-Address has
chosen for the association.
The VTag is a unique 32-bit tag that accompanies any outgoing SCTP packet for
this association to the Remote-Address.</t></dd>
</dl>
<t>[NOTE to RFC-Editor: Assignment of parameter type to be confirmed by IANA.]</t>
<t>The VTags Parameter MAY appear in ASCONF chunks and MUST NOT appear in
any other chunk.</t>
</section>
</section>
</section>
<section>
<name>Procedures for SCTP Endpoints and NAT Functions</name>
<t>If an SCTP endpoint is behind an SCTP-aware NAT, a
number of problems can arise as it tries to communicate with its peers:</t>
<ul>
<li><t>IP addresses can not be included in the SCTP packet. This is
discussed in <xref target='setup'/>.</t></li>
<li><t>More than one host behind a NAT function could select the same VTag and source
port number when communicating with the same peer server.
This creates a situation where the NAT function will not be able to tell the
two associations apart.
This situation is discussed in <xref target='mbitport'/>.</t></li>
<li><t>If an SCTP endpoint is a server communicating with multiple peers and the
peers are behind the same NAT function, then the these peers cannot be
distinguished by the server. This case is discussed in <xref target='collision'/>.</t></li>
<li><t>A restart of a NAT function during a conversation could cause a loss of its state.
This problem and its solution is discussed in <xref target='restart'/>.</t></li>
<li><t>NAT functions need to deal with SCTP packets being fragmented at the IP layer.
This is discussed in <xref target='fragmentation'/>.</t></li>
<li><t>An SCTP endpoint can be behind two NAT functions in parallel providing
redundancy.
The method to set up this scenario is discussed in <xref target='multihomed'/>.</t></li>
</ul>
<t>The mechanisms to solve these problems require additional chunks and
parameters, defined in this document, and modified handling procedures
from those specified in <xref target='RFC4960'/> as described below.</t>
<section anchor='setup'>
<name>Association Setup Considerations for Endpoints</name>
<t>The association setup procedure defined in <xref target='RFC4960'/>
allows multi-homed SCTP endpoints to exchange its IP-addresses by using
IPv4 or IPv6 address parameters in the INIT and INIT ACK chunks.
However, this does not work when NAT functions are present.</t>
<t>Every association setup from a host behind a NAT function MUST NOT use multiple
internal addresses.
The INIT chunk MUST NOT contain an IPv4 Address parameter,
IPv6 Address parameter, or Supported Address Types parameter.
The INIT ACK chunk MUST NOT contain any IPv4 Address parameter or
IPv6 Address parameter using non-global addresses.
The INIT chunk and the INIT ACK chunk MUST NOT contain any Host Name
parameters.</t>
<t>If the association is intended to be finally multi-homed, the procedure in
<xref target='multihomed'/> MUST be used.</t>
<t>The INIT and INIT ACK chunk SHOULD contain the Disable Restart parameter
defined in <xref target='disrestart'/>.</t>
</section>
<section anchor='mbitport'>
<name>Handling of Internal Port Number and Verification Tag Collisions</name>
<t>Consider the case where two hosts in the Internal-Address space want to
set up an SCTP association with the same service provided by some remote hosts.
This means that the Remote-Port is the same.
If they both choose the same Internal-Port and Internal-VTag, the
NAT function cannot distinguish between incoming packets anymore.
However, this is unlikely.
The Internal-VTags are chosen at random and if the Internal-Ports are
also chosen from the ephemeral port range at random (see <xref target='RFC6056'/>)
this gives a 46-bit random number that has to match.</t>
<t>The same can happen with the Remote-VTag when a packet containing an
INIT ACK chunk or an ASCONF chunk is processed by the NAT function.</t>
<section>
<name>NAT Function Considerations</name>
<t>If the NAT function detects a collision of internal port numbers and
verification tags, it SHOULD send a packet containing an ABORT chunk with the
M bit set if the collision is triggered by a packet containing an INIT or
INIT ACK chunk.
If such a collision is triggered by a packet containing an ASCONF chunk,
it SHOULD send a packet containing an ERROR chunk with the M bit.
The M bit is a new bit defined by this document to express to
SCTP that the source of this packet is a "middle" box, not the
peer SCTP endpoint (see <xref target="mbitabort"/>).
If a packet containing an INIT ACK chunk triggers the collision,
the corresponding packet containing the ABORT chunk MUST contain the same
source and destination address and port numbers as the packet containing
the INIT ACK chunk. If a packet containing an INIT chunk or an ASCONF chunk,
the source and destination address and port numbers MUST be swapped.</t>
<t>The sender of the packet containing an ERROR or ABORT chunk MUST include
the error cause with cause code 'VTag and Port Number Collision'
(see <xref target='port_coll'/>).</t>
</section>
<section>
<name>Endpoint Considerations</name>
<t>The sender of the packet containing the INIT chunk or the receiver
of a packet containing the INIT ACK chunk, upon reception of a packet containing
an ABORT chunk with M bit set and the appropriate error cause code for
colliding NAT binding table state is included, SHOULD reinitiate the
association setup procedure after choosing a new initiate tag,
if the association is in COOKIE-WAIT state.
In any other state, the SCTP endpoint MUST NOT respond.</t>
<t>The sender of the packet containing the ASCONF chunk, upon reception of a
packet containing an ERROR chunk with M bit set, MUST stop adding the path to
the association.</t>
</section>
</section>
<section anchor='collision'>
<name>Handling of Internal Port Number Collisions</name>
<t>When two SCTP hosts are behind an SCTP-aware NAT it is possible that two
SCTP hosts in the Internal-Address space will want to set up an
SCTP association with the same server running on the same remote host.
If the two hosts choose the same internal port, this is considered an
internal port number collision.</t>
<t>For the NAT function, appropriate tracking can be performed by assuring that
the VTags are unique between the two hosts.</t>
<section>
<name>NAT Function Considerations</name>
<t>The NAT function, when processing the packet containing the INIT ACK chunk,
SHOULD note in its NAT binding table if the association supports the
disable restart extension.
This note is used when establishing future associations (i.e. when processing
a packet containing an INIT chunk from an internal host) to decide if the
connection can be allowed.
The NAT function does the following when processing a packet containing an
INIT chunk:</t>
<ul>
<li><t>If the packet containing the INIT chunk is originating from an internal
port to a remote port for which the NAT function has no matching NAT binding
table entry, it MUST allow the packet containing the INIT chunk creating
an NAT binding table entry.</t></li>
<li><t>If the packet containing the INIT chunk matches an existing NAT binding
table entry, it MUST validate that the disable restart feature is supported and,
if it does, allow the packet containing the INIT chunk to be forwarded.</t></li>
<li><t>If the disable restart feature is not supported, the NAT function SHOULD
send a packet containing an ABORT chunk with the M bit set.</t></li>
</ul>
<t>The 'Port Number Collision' error cause (see <xref target='portcollide' />)
MUST be included in the ABORT chunk sent in response to the packet containing
an INIT chunk.</t>
<t>If the collision is triggered by a packet containing an ASCONF chunk,
a packet containing an ERROR chunk with the 'Port Number Collision' error cause
SHOULD be sent in response to the packet containing the ASCONF chunk.</t>
</section>
<section>
<name>Endpoint Considerations</name>
<t>For the remote SCTP server this means that the Remote-Port and the
Remote-Address are the same.
If they both have chosen the same Internal-Port the server cannot distinguish
between both associations based on the address and port numbers.
For the server it looks like the association is being restarted.
To overcome this limitation the client sends a Disable Restart parameter in
the INIT chunk.</t>
<t>When the server receives this parameter it does the following:</t>
<ul>
<li><t>It MUST include a Disable Restart parameter in the INIT ACK to
inform the client that it will support the feature.</t></li>
<li><t>It MUST disable the restart procedures defined in <xref target='RFC4960'/>
for this association.</t></li>
</ul>
<t>Servers that support this feature will need to be capable of maintaining
multiple connections to what appears to be the same peer
(behind the NAT function) differentiated only by the VTags.</t>
</section>
</section>
<section anchor='restart'>
<name>Handling of Missing State</name>
<section>
<name>NAT Function Considerations</name>
<t>If the NAT function receives a packet from the internal network
for which the lookup procedure does not find an entry in the NAT binding table,
a packet containing an ERROR chunk SHOULD be sent back with the M bit set.
The source address of the packet containing the ERROR chunk MUST
be the destination address of the packet received from the internal network.
The verification tag is reflected and the T bit is set.
Such a packet containing an ERROR chunk SHOULD NOT
be sent if the received packet contains an ASCONF chunk with the VTags parameter
or an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk.
A packet containing an ERROR chunk MUST NOT be sent if the
received packet contains an ERROR chunk with the M bit set.
In any case, the packet SHOULD NOT be forwarded to the remote address.</t>
<t>If the NAT function receives a packet from the internal network for which it
has no NAT binding table entry and the packet contains an ASCONF chunk with the
VTags parameter, the NAT function MUST update its NAT binding table according
to the verification tags in the VTags parameter and, if present, the
Disable Restart parameter.</t>
<t>When sending a packet containing an ERROR chunk, the error cause
'Missing State' (see <xref target='miss_state'/>) MUST be included and the
M bit of the ERROR chunk MUST be set (see <xref target='mbiterr'/>).</t>
</section>
<section>
<name>Endpoint Considerations</name>
<t>Upon reception of this packet containing the ERROR chunk by an SCTP endpoint
the receiver takes the following actions:</t>
<ul>
<li><t>It SHOULD validate that the verification tag is reflected by looking
at the VTag that would have been included in an outgoing packet.
If the validation fails, discard the received packet containing the ERROR chunk.</t></li>
<li><t>It SHOULD validate that the peer of the SCTP association supports
the dynamic address extension.
If the validation fails, discard the received packet containing the ERROR chunk.</t></li>
<li><t>It SHOULD generate a packet containing a new ASCONF chunk containing the
VTags parameter (see <xref target='vtags-parameter'/>) and the Disable Restart
parameter (see <xref target='disrestart'/>) if the association is using the
disable restart feature.
By processing this packet the NAT function can recover the appropriate state.
The procedures for generating an ASCONF chunk can be found in
<xref target='RFC5061'/>.</t></li>
</ul>
<t>The peer SCTP endpoint receiving such a packet containing an ASCONF chunk
SHOULD add the address and respond with an acknowledgment if the
address is new to the association (following all procedures defined in
<xref target='RFC5061'/>).
If the address is already part of the association, the SCTP endpoint
MUST NOT respond with an error, but instead SHOULD respond with a packet
containing an ASCONF ACK chunk acknowledging the address and take no action
(since the address is already in the association).</t>
<t>Note that it is possible that upon receiving a packet containing an
ASCONF chunk containing the VTags parameter the NAT function will realize that it has an
'Internal Port Number and Verification Tag collision'.
In such a case the NAT function SHOULD send a packet containing an ERROR chunk with the
error cause code set to 'VTag and Port Number Collision'
(see <xref target='port_coll'/>).</t>
<t>If an SCTP endpoint receives a packet containing an ERROR chunk with
'Internal Port Number and Verification Tag collision' as the error cause
and the packet in the Error Chunk contains an ASCONF with
the VTags parameter, careful examination of the association is necessary.
The endpoint does the following:</t>
<ul>
<li><t>It MUST validate that the verification tag is reflected by looking
at the VTag that would have been included in the outgoing
packet. If the validation fails, it MUST discard the packet.</t></li>
<li><t>It MUST validate that the peer of the SCTP association supports
the dynamic address extension. If the peer does not support this extension,
it MUST discard the received packet containing the ERROR chunk.</t></li>
<li><t>If the association is attempting to add an address (i.e. following
the procedures in <xref target='multihomed'/>) then the endpoint MUST NOT
consider the address part of the association and SHOULD make no
further attempt to add the address (i.e. cancel any ASCONF timers and
remove any record of the path), since the NAT function has a VTag collision
and the association cannot easily create a new VTag (as it would if
the error occurred when sending a packet containing an INIT chunk).</t></li>
<li><t>If the endpoint has no other path, i.e. the procedure was executed
due to missing a state in the NAT function, then the endpoint MUST abort the
association.
This would occur only if the local NAT function restarted and accepted a new
association before attempting to repair the missing state (Note that this
is no different than what happens to all TCP connections when a NAT function
looses its state).</t></li>
</ul>
</section>
</section>
<section anchor='fragmentation'>