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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
|
Document: draft-cheshire-nat-pmp-02.txt Stuart Cheshire
Internet-Draft Marc Krochmal
Category: Standards Track Apple Computer, Inc.
Expires 14th March 2007 Kiren Sekar
Sharpcast, Inc.
14th September 2006
NAT Port Mapping Protocol (NAT-PMP)
<draft-cheshire-nat-pmp-02.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
For the purposes of this document, the term "BCP 79" refers
exclusively to RFC 3979, "Intellectual Property Rights in IETF
Technology", published March 2005.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes a protocol for automating the process of
creating Network Address Translation (NAT) port mappings. Included
in the protocol is a method for retrieving the public IP address of
a NAT gateway, thus allowing a client to make this public IP address
and port number known to peers that may wish to communicate with it.
This protocol is implemented in current Apple products including
Mac OS X, Bonjour for Windows, and AirPort wireless base stations.
Expires 14th March 2007 Cheshire, et al. [Page 1]
Internet Draft NAT Port Mapping Protocol 14th September 2006
1. Introduction
Network Address Translation (NAT) is a method of sharing one public
internet address with a number of devices. This document is focused
on what "IP Network Address Translator (NAT) Terminology and
Considerations" [RFC 2663] calls "NAPTs" (Network Address/Port
Translators). A full description of NAT is beyond the scope of this
document. The following brief overview will cover the aspects
relevant to this port mapping protocol. For more information on
NAT, see "Traditional IP Network Address Translator" [RFC 3022].
NATs have one or more public IP addresses. A private network is set
up behind the NAT. Devices behind the NAT are assigned private
addresses and the private address of the NAT device is used as the
gateway.
When a packet from any device behind the NAT is sent to an address on
the public internet, the packet first passes through the NAT box. The
NAT box looks at the source port and address. In some cases, a NAT
will also keep track of the destination port and address. The NAT
then creates a mapping from the private address and private port to a
public address and public port if a mapping does not already exist.
The NAT box replaces the private address and port number in the
packet with the public entries from the mapping and sends the packet
on to the next gateway.
When a packet from any address on the internet is received on the
NAT's public side, the NAT will look up the destination port (public
port) in the list of mappings. If an entry is found, it will contain
the private address and port that the packet should be sent to. The
NAT gateway will then rewrite the destination address and port with
those from the mapping. The packet will then be forwarded to the new
destination addresses. If the packet did not match any mapping, the
packet will most likely be dropped. Various NATs implement different
strategies to handle this. The important thing to note is that if
there is no mapping, the NAT does not know which private address the
packet should be sent to.
Mappings are usually created automatically as a result of observing
outbound traffic. There are a few exceptions. Some NATs may allow
manually-created permanent mappings that map a public port to a
specific private IP address and port. Such a mapping allows incoming
connections to the device with that private address. Some NATs also
implement a default mapping where any inbound traffic that does not
match a mapping will always be forwarded to a specific private
address. Both types of mappings are usually set up manually through
some configuration tool.
Without these manually-created inbound port mappings, clients behind
the NAT would be unable to receive inbound connections, which
represents a loss of connectivity when compared to the original
Expires 14th March 2007 Cheshire, et al. [Page 2]
Internet Draft NAT Port Mapping Protocol 14th September 2006
Internet architecture [ETEAISD]. For those who view this loss of
connectivity as a bad thing, NAT-PMP allows clients to operate much
more like a host directly connected to the unrestricted public
Internet, with an unrestricted public IP address. NAT-PMP allows
client hosts to communicate with the NAT gateway to request the
creation of inbound mappings on demand. Having created a NAT mapping
to allow inbound connections, the client can then record its public
IP address and public port number in a public registry (e.g. the
world-wide Domain Name System) or otherwise make it accessible to
peers that wish to communicate with it.
2. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC 2119].
3. Protocol and Packet Format
NAT Port Mapping Protocol runs over UDP. Every packet starts with an
8 bit version followed by an 8 bit operation code.
This document specifies version 0 of the protocol. Any NAT-PMP
gateway implementing this version of the protocol, receiving a
packet with a version number other than 0, MUST return result code 1
(Unsupported Version).
Opcodes between 0 and 127 are client requests. Opcodes from 128 to
255 are server responses. Responses always contain a 16 bit result
code in network byte order. A result code of zero indicates success.
Responses also contain a 32 bit unsigned integer corresponding to the
number of seconds since the NAT gateway was rebooted or since its
port mapping state was reset.
This protocol SHOULD only be used when the client determines that
its primary IPv4 address is in one of the private IP address ranges
defined in "Address Allocation for Private Internets" [RFC 1918].
This includes the address ranges 10/8, 172.16/12, and 192.168/16.
Clients always send their Port Mapping Protocol requests to their
default gateway, as learned via DHCP [RFC 2131], or similar means.
This protocol is designed for small home networks, with a single
logical link (subnet) where the client's default gateway is also the
NAT translator for that network. For more complicated networks where
the NAT translator is some device other than the client's default
gateway, this protocol is not appropriate.
Expires 14th March 2007 Cheshire, et al. [Page 3]
Internet Draft NAT Port Mapping Protocol 14th September 2006
3.1 Requests and Responses
NAT gateways are often low-cost devices, with limited memory and
CPU speed. For this reason, to avoid making excessive demands on
the NAT gateway, clients machines SHOULD NOT issue multiple requests
simultaneously in parallel. If a client needs to perform multiple
requests (e.g. on boot, wake from sleep, network connection, etc.)
it SHOULD queue them and issue them serially one at a time. Once the
NAT gateway responds to one request the client machine may issue the
next. In the case of a fast NAT gateway, the client may be able to
complete requests at a rate of hundreds per second. In the case of
a slow NAT gateway that takes perhaps half a second to respond to
a NAT-PMP request, the client SHOULD respect this and allow the
NAT gateway to operate at the pace it can manage, and not overload
it by issuing requests faster than the rate it's answering them.
To determine the puclic IP address or request a port mapping,
a NAT-PMP client sends its request packet to port 5351 of its
configured gateway address, and waits 250ms for a response. If no
NAT-PMP response is received from the gateway after 250ms, the client
retransmits its request and waits 500ms. The client SHOULD repeat
this process with the interval between attempts doubling each time.
If, after sending its 9th attempt (and then waiting for 64 seconds),
the client has still received no response, then it SHOULD conclude
that this gateway does not support NAT Port Mapping Protocol and
MAY log an error message indicating this fact. In addition, if the
NAT-PMP client receives an "ICMP Port Unreachable" message from the
gateway for port 5351 then it can skip any remaining retransmissions
and conclude immediately that the gateway does not support NAT-PMP.
As a performance optimization the client MAY record this information
and use it to suppress further attempts to use NAT-PMP, but the
client should not retain this information for too long. In
particular, any event that may indicate a potential change of gateway
or a change in gateway configuration (hardware link change
indication, change of gateway MAC address, acquisition of new DHCP
lease, receipt of NAT-PMP announcement packet from gateway, etc.)
should cause the client to discard its previous information regarding
the gateway's lack of NAT-PMP support, and send its next NAT-PMP
request packet normally.
3.2 Determining the Public Address
To determine the public address, the client behind the NAT sends the
following UDP payload to port 5351 of the configured gateway address:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires 14th March 2007 Cheshire, et al. [Page 4]
Internet Draft NAT Port Mapping Protocol 14th September 2006
A compatible NAT gateway MUST generate a response with the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + 0 | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public IP Address (a.b.c.d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This response indicates that the NAT gateway implements this version
of the protocol and returns the public IP address of the NAT gateway.
If the result code is non-zero, the value of Public IP Address is
undefined (MUST be set to zero on transmission, and MUST be ignored
on reception).
The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field
with the time elapsed since its port mapping table was initialized on
startup or reset for any other reason (see Section 3.6 "Seconds Since
Start of Epoch").
Upon receiving the response packet, the client MUST check the source
IP address, and silently discard the packet if the address is not the
address of the gateway to which the request was sent.
3.2.1 Announcing Address Changes
When the public IP address of the NAT changes, the NAT gateway MUST
send a gratuitous response to the link-local multicast address
224.0.0.1, port 5351 with the packet format above to notify clients
of the new public IP address. To accommodate packet loss, the
NAT gateway SHOULD multicast 10 address change notifications.
The interval between the first two notifications SHOULD be 250ms,
and the interval between each subsequent notification SHOULD double.
Upon receiving a gratuitous address change announcement packet,
the client MUST check the source IP address, and silently discard
the packet if the address is not the address of the client's
current configured gateway. This is to guard against inadvertent
misconfigurations where there may be more than one NAT gateway
active on the network.
Expires 14th March 2007 Cheshire, et al. [Page 5]
Internet Draft NAT Port Mapping Protocol 14th September 2006
3.3 Creating a Mapping
To create a mapping, the client sends a UDP packet to port 5351
of the gateway's private IP address with the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = x | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Port | Requested Public Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcodes supported:
1 - Map UDP
2 - Map TCP
The Reserved field MUST be set to zero on transmission and MUST
be ignored on reception.
The Private Port is set to the local port on which the client is
listening.
The Requested Public Port SHOULD usually be set to the same value as
the local Private Port, or zero if the client has no preference for
what port is assigned. However, the gateway is not obliged to assign
the port requested, and may choose not to, either for policy reasons
(e.g. port 80 is reserved and clients may not request it) or because
that port has already been assigned to some other client. Because
of this, some product developers have questioned the value of having
the Requested Public Port field at all. The reason is for failure
recovery. Most low-cost home NAT gateways do not record temporary
port mappings in persistent storage, so if the gateway crashes or is
rebooted, all the mappings are lost. A renewal packet is formatted
identically to an initial mapping request packet, except that for
renewals the client sets the Requested Public Port field to the
port the gateway actually assigned, rather than the port the client
originally wanted. When a freshly-rebooted NAT gateway receives a
renewal packet from a client, it appears to the gateway just like
an ordinary initial request for a port mapping, except that in this
case the Requested Public Port is likely to be one that the NAT
gateway *is* willing to allocate (it allocated it to this client
right before the reboot, so it should presumably be willing to
allocate it again).
The RECOMMENDED Port Mapping Lifetime is 3600 seconds.
Expires 14th March 2007 Cheshire, et al. [Page 6]
Internet Draft NAT Port Mapping Protocol 14th September 2006
After sending the port mapping request, the client then waits for the
NAT gateway to respond. If after 250ms, the gateway doesn't respond,
the client SHOULD re-issue its request as described above in Section
3.1 "Requests and Responses".
The NAT gateway responds with the following packet format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + x | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Port | Mapped Public Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'x' in the OP field MUST match what the client requested. Some
NAT gateways are incapable of creating a UDP port mapping without
also creating a corresponding TCP port mapping, and vice versa, and
these gateways MUST NOT implement NAT Port Mapping Protocol until
this deficiency is fixed. A NAT gateway which implements this
protocol MUST be able to create TCP-only and UDP-only port mappings.
If a NAT gateway silently creates a pair of mappings for a client
that only requested one mapping, then it may expose that client to
receiving inbound UDP packets or inbound TCP connection requests
that it did not ask for and does not want.
While a NAT gateway MUST NOT automatically create mappings for TCP
when the client requests UDP, and vice versa, the NAT gateway MUST
reserve the companion port so the same client can choose to map it
in the future. For example, if a client requests to map TCP port 80,
as long as the client maintains the lease for that TCP port mapping,
another client with a different IP address MUST NOT be able to
successfully acquire the mapping for UDP port 80.
The client normally requests the public port matching the private
port. If that public port is not available, the NAT gateway MUST
return a public port that is available or return an error code if
no ports are available.
The source address of the packet MUST be used for the private address
in the mapping. This protocol is not intended to facilitate one
device behind a NAT creating mappings for other devices. If there
are legacy devices that require inbound mappings, permanent mappings
can be created manually by the administrator, just as they are today.
Expires 14th March 2007 Cheshire, et al. [Page 7]
Internet Draft NAT Port Mapping Protocol 14th September 2006
If a mapping already exists for a given private port on a given local
client (whether that mapping was created explicitly using NAT-PMP,
implicitly as a result of an outgoing TCP SYN packet, or manually by
a human administrator) and that client requests another mapping for
the same private port (possibly requesting a different public port)
then the mapping request should succeed, returning the already-
assigned public port. This is necessary to handle the case where
a client requests a mapping with requested public port X, and is
granted a mapping with actual public port Y, but the acknowledgement
packet gets lost. When the client retransmits its mapping request,
it should get back the same positive acknowledgement as was sent (and
lost) the first time.
The NAT gateway SHOULD NOT accept mapping requests destined to the
NAT gateway's public IP address or received on its public network
interface. Only packets received on the private interface(s) with
a destination address matching the private address(es) of the NAT
gateway should be allowed.
The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field
with the time elapsed since its port mapping table was initialized on
startup or reset for any other reason (see Section 3.6 "Seconds Since
Start of Epoch").
The Port Mapping Lifetime is an unsigned integer in seconds. The NAT
gateway MAY reduce the lifetime from what the client requested. The
NAT gateway SHOULD NOT offer a lease lifetime greater than that
requested by the client.
Upon receiving the response packet, the client MUST check the source
IP address, and silently discard the packet if the address is not the
address of the gateway to which the request was sent.
The client SHOULD begin trying to renew the mapping halfway to expiry
time, like DHCP. The renewal packet should look exactly the same as
a request packet, except that the client SHOULD set the requested
public port to what the NAT gateway previously mapped, not what the
client originally requested. As described above, this enables the
gateway to automatically recover its mapping state after a crash or
reboot.
3.4 Destroying a Mapping
A mapping may be destroyed in a variety of ways. If a client fails
to renew a mapping, then when its lifetime expires the mapping MUST
be automatically deleted. In the common case where the gateway
device is a combined DHCP server and NAT gateway, when a client's
DHCP address lease expires, the gateway device MAY automatically
delete any mappings belonging to that client. Otherwise a new client
being assigned the same IP address could receive unexpected inbound
Expires 14th March 2007 Cheshire, et al. [Page 8]
Internet Draft NAT Port Mapping Protocol 14th September 2006
UDP packets or inbound TCP connection requests that it did not ask
for and does not want.
A client MAY also send an explicit packet to request deletion of a
mapping that is no longer needed. A client requests explicit
deletion of a mapping by sending a message to the NAT gateway
requesting the mapping, with the Requested Lifetime in Seconds set
to 0. The requested public port MUST be set to zero by the client
on sending, and MUST be ignored by the gateway on reception.
When a mapping is destroyed successfully as a result of the client
explicitly requesting the deletion, the NAT gateway MUST send a
response packet which is formatted as defined in section 3.3
"Creating a Mapping". The response MUST contain a result code of 0,
the private port as indicated in the deletion request, a public port
of 0, and a lifetime of 0. The NAT gateway MUST respond to a request
to destroy a mapping that does not exist as if the request were
successful. This is because of the case where the acknowledgement is
lost, and the client retransmits its request to delete the mapping.
In this case the second request to delete the mapping MUST return the
same response packet as the first request.
If the deletion request was unsuccessful, the response MUST contain a
non-zero result code and the requested mapping; the lifetime is
undefined (MUST be set to zero on transmission, and MUST be ignored
on reception). If the client attempts to delete a port mapping which
was manually assigned by some kind of configuration tool, the NAT
gateway MUST respond with a 'Not Authorized' error, result code 2.
When a mapping is destroyed as a result of its lifetime expiring or
for any other reason, if the NAT gateway's internal state indicates
that there are still active TCP connections traversing that now-
defunct mapping, then the NAT gateway SHOULD send appropriately-
constructed TCP RST (reset) packets both to the local client and to
the remote peer on the Internet to terminate that TCP connection.
A client can request the explicit deletion of all its UDP or TCP
mappings by sending the same deletion request to the NAT gateway
with public port, private port, and lifetime set to 0. A client MAY
choose to do this when it first acquires a new IP address in order to
protect itself from port mappings that were performed by a previous
owner of the IP address. After receiving such a deletion request,
the gateway MUST delete all its UDP or TCP port mappings (depending
on the opcode). The gateway responds to such a deletion request with
a response as described above, with the private port set to zero. If
the gateway is unable to delete a port mapping, for example, because
the mapping was manually configured by the administrator, the gateway
MUST still delete as many port mappings as possible, but respond with
a non-zero result code. The exact result code to return depends on
the cause of the failure. If the gateway is able to successfully
delete all port mappings as requested, it MUST respond with a result
code of 0.
Expires 14th March 2007 Cheshire, et al. [Page 9]
Internet Draft NAT Port Mapping Protocol 14th September 2006
3.5 Result Codes
Currently defined result codes:
0 - Success
1 - Unsupported Version
2 - Not Authorized/Refused
(e.g. box supports mapping, but user has turned feature off)
3 - Network Failure
(e.g. NAT box itself has not obtained a DHCP lease)
4 - Out of resources
(NAT box cannot create any more mappings at this time)
5 - Unsupported opcode
If the result code is non-zero, the format of the packet following
the result code may be truncated. For example, if the client sends a
request to the server with an opcode of 17 and the server does not
recognize that opcode, the server SHOULD respond with a message where
the opcode is 17 + 128 and the result code is 5 (opcode not
supported). Since the server does not understand the format of
opcode 17, it may not know what to place after the result code. In
some cases, relevant data may follow the opcode to identify the
operation that failed. For example, a client may request a mapping
but that mapping may fail due to resource exhaustion. The server
SHOULD respond with the result code to indicate resource exhaustion
(4) followed by the requested port mapping so the client may identify
which operation failed.
Clients MUST be able to properly handle result codes not defined in
this document. Undefined results codes MUST be treated as fatal
errors of the request.
3.6 Seconds Since Start of Epoch
Every packet sent by the NAT gateway includes a "Seconds since start
of epoch" field (SSSOE). If the NAT gateway resets or loses the
state of its port mapping table, due to reboot, power failure, or any
other reason, it MUST reset its epoch time and begin counting SSSOE
from 0 again. Whenever a client receives any packet from the NAT
gateway, either gratuitously or in response to a client request, the
client computes its own conservative estimate of the expected SSSOE
value by taking the SSSOE value in the last packet it received from
the gateway and adding 7/8 (87.5%) of the time elapsed since that
packet was received. If the SSSOE in the newly received packet is
less than the client's conservative estimate by more than one second,
then the client concludes that the NAT gateway has undergone a reboot
or other loss of port mapping state, and the client MUST immediately
renew all its active port mapping leases as described in Section 3.7
"Recreating Mappings On NAT Gateway Reboot".
Expires 14th March 2007 Cheshire, et al. [Page 10]
Internet Draft NAT Port Mapping Protocol 14th September 2006
3.7 Recreating Mappings On NAT Gateway Reboot
The NAT gateway MAY store mappings in persistent storage so when it
is powered off or rebooted, it remembers the port mapping state of
the network.
However, maintaining this state is not essential for correct
operation. When the NAT gateway powers on or clears its port mapping
state as the result of a configuration change, it MUST reset the
epoch time and re-announce its IP address as described in Section
3.2.1 "Announcing Address Changes". Reception of this packet where
time has apparently gone backwards serves as a hint to clients
on the network that they SHOULD immediately send renewal packets
(to immediately recreate their mappings) instead of waiting until
the originally scheduled time for those renewals. Clients who miss
receiving those gateway announcement packets for any reason will
still renew their mappings at the originally scheduled time and cause
their mappings to be recreated; it will just take a little longer for
these clients.
A mapping renewal packet is formatted identically to an original
mapping request; from the point of view of the client it is a
renewal of an existing mapping, but from the point of view of the
freshly-rebooted NAT gateway it appears as a new mapping request.
This self-healing property of the protocol is very important.
The remarkable reliability of the Internet as a whole derives
in large part from the fact that important state is held in the
endpoints, not in the network itself [ETEAISD]. Power-cycling an
Ethernet switch results only in a brief interruption in the flow
of packets; established TCP connections through that switch are not
broken, merely delayed for a few seconds. Indeed, an old Ethernet
switch can even be replaced with a new one, and as long as the cables
are transferred over reasonably quickly, after the upgrade all the
TCP connections that were previously going though the old switch will
be unbroken and now going through the new one. The same is true of
IP routers, wireless base stations, etc. The one exception is NAT
gateways. Because the port mapping state is required for the NAT
gateway to know where to forward inbound packets, loss of that state
breaks connectivity through the NAT gateway. By allowing clients to
detect when this loss of NAT gateway state has occurred, and recreate
it on demand, we turn hard state in the network into soft state, and
allow it to be recovered automatically when needed.
Without this automatic recreation of soft state in the NAT gateway,
reliable long-term networking would not be achieved. As mentioned
above, the reliability of the Internet does not come from trying
to build a perfect network in which errors never happen, but from
accepting that in any sufficiently large system there will always be
some component somewhere that's failing, and designing mechanisms
Expires 14th March 2007 Cheshire, et al. [Page 11]
Internet Draft NAT Port Mapping Protocol 14th September 2006
that can handle those failures and recover. To illustrate this point
with an example, consider the following scenario: Imagine a network
security camera that has a web interface and accepts incoming
connections from web browser clients. Imagine this network security
camera uses NAT-PMP or a similar protocol to set up an inbound
port mapping in the NAT gateway so that it can receive incoming
connections from clients the other side of the NAT gateway.
Now, this camera may well operate for weeks, months, or even years.
During that time it's possible that the NAT gateway could experience
a power failure or be rebooted. The user could upgrade the NAT
gateway's firmware, or even replace the entire NAT gateway device
with a newer model. The general point is that if the camera operates
for a long enough period of time, some kind of disruption to the NAT
gateway becomes inevitable. The question is not whether the NAT
gateway will lose its port mappings, but when, and how often.
If the network camera and devices like it on the network can detect
when the NAT gateway has lost its port mappings, and recreate them
automatically, then these disruptions are self-correcting and
invisible to the end user. If, on the other hand, the disruptions are
not self-correcting, and after a NAT gateway reboot the user has to
manually reset or reboot all the other devices on the network too,
then these disruptions are *very* visible to the end user. This
aspect of the design is what makes the difference between a protocol
that keeps on working indefinitely over a time scale of months or
years, and a protocol that works in brief testing, but in the real
world is continually failing and requiring manual intervention to get
it going again.
When a client renews its port mappings as the result of receiving
a packet where the "Seconds since start of epoch" field (SSSOE)
indicates that a reboot or similar loss of state has occurred,
the client MUST first delay by a random amount of time selected
with uniform random distribution in the range 0 to 5 seconds, and
then send its first port mapping request. After that request is
acknowledged by the gateway, the client may then send its second
request, and so on, as rapidly as the gateway allows. The requests
SHOULD be issued serially, one at a time; the client SHOULD NOT issue
multiple requests simultaneously in parallel.
The discussion in this section focusses on recreating inbound port
mappings after loss of NAT gateway state, because that is the more
serious problem. Losing port mappings for outgoing connections
destroys those currently active connections, but does not prevent
clients from establishing new outgoing connections. In contrast,
losing inbound port mappings not only destroys all existing inbound
connections, but also prevents the reception of any new inbound
connections until the port mapping is recreated. Accordingly,
we consider recovery of inbound port mappings the more important
priority. However, clients that want outgoing connections to survive
a NAT gateway reboot can also achieve that using NAT-PMP. After
initiating an outbound TCP connection (which will cause the NAT
Expires 14th March 2007 Cheshire, et al. [Page 12]
Internet Draft NAT Port Mapping Protocol 14th September 2006
gateway to establish an implicit port mapping) the client should send
the NAT gateway a port mapping request for the source port of its TCP
connection, which will cause the NAT gateway to send a response
giving the public port it allocated for that mapping. The client can
then store this information, and use later to recreate the mapping
if it determines that the NAT gateway has lost its mapping state.
3.8 NAT Gateways with NAT Function Disabled
Note that *only* devices currently acting in the role of NAT gateway
should participate in NAT-PMP protocol exchanges with clients.
A network device that is capable of NAT (and NAT-PMP), but is
currently configured not to perform that function, (e.g. it is
acting as a traditional IP router, forwarding packets without
modifying them), MUST NOT respond to NAT-PMP requests from clients,
or send spontaneous NAT-PMP address-change announcements.
In particular, a network device not currently acting in the role of
NAT gateway should not even respond to NAT-PMP requests by returning
an error code such as "2 - Not Authorized/Refused", since to do so
is misleading to clients -- it suggests that NAT port mapping is
necessary on this network for the client to successfully receive
inbound connections, but is not available because the administrator
has chosen to disable that functionality.
Clients should also be careful to avoid making unfounded assumptions,
such as the assumption that if the client has an IPv4 address in
one of the RFC 1918 private IP address ranges then that means
NAT necessarily must be in use. Net 10/8 has enough addresses
to build a private network with millions of hosts and thousands
of interconnected subnets, all without any use of NAT. Many
organizations have built such private networks that benefit from
using standard TCP/IP technology, but by choice do not connect
to the public Internet. The purpose of NAT-PMP is to mitigate some
of the damage caused by NAT. It would be an ironic and unwanted
side-effect of this protocol if it were to lead well-meaning but
misguided developers to create products that refuse to work on a
private network *unless* they can find a NAT gateway to talk to.
Consequently, a client finding that NAT-PMP is not available on its
network should not give up, but should proceed on the assumption
that the network may be a traditional routed IP network, with no
address translation being used. This assumption may not always be
true, but it is better than the alternative of falsely assuming
the worst and not even trying to use normal (non-NAT) IP networking.
If a network device not currently acting in the role of NAT gateway
receives UDP packets addressed to port 5351, it SHOULD respond
immediately with an "ICMP Port Unreachable" message to tell the
client that it needn't continue with timeouts and retransmissions,
and it should assume that NAT-PMP is not available and not needed
on this network.
Expires 14th March 2007 Cheshire, et al. [Page 13]
Internet Draft NAT Port Mapping Protocol 14th September 2006
4. UNSAF Considerations
The document "IAB Considerations for UNSAF Across NAT" [RFC 3424]
covers a number of issues when working with NATs. RFC 3424 outlines
some requirements for any document that attempts to work around
problems associated with NATs. This section addresses those
requirements.
4.1 Scope
This protocol addresses the needs of TCP and UDP transport peers that
are separated from the public internet by exactly one NAT. Such
peers must have access to some form of directory server for
registering the public IP address and port at which they can be
reached.
4.2 Transition Plan
Any client making use of this protocol SHOULD implement IPv6 support.
If a client supports IPv6 and is running on a device with a global
IPv6 address, that IPv6 address SHOULD be preferred to the IPv4
public address using this NAT mapping protocol. In case other
clients do not have IPv6 connectivity, both the IPv4 and IPv6
addresses SHOULD be registered with whatever form of directory server
is used. Preference SHOULD be given to IPv6 addresses when
available. By implementing support for IPv6 and using this protocol
for IPv4, vendors can ship products today that will work under both
scenarios. As IPv6 is more widely deployed, clients of this protocol
following these recommendations will transparently make use of IPv6.
4.3 Failure Cases
Aside from NATs that do not implement this protocol, there are a
number of situations where this protocol may not work.
4.3.1 NAT Behind NAT
Some people's primary IP address, assigned by their ISP, may itself
be a NAT address. In addition, some people may have a public IP
address, but may then double NAT themselves, perhaps by choice or
perhaps by accident. Although it might be possible in principle for
one NAT gateway to recursively request a mapping from the next one,
this document does not advocate that and does not try to prescribe
how it would be done.
It would be a lot of work to implement nested NAT port mapping
correctly, and there are a number of reasons why the end result might
Expires 14th March 2007 Cheshire, et al. [Page 14]
Internet Draft NAT Port Mapping Protocol 14th September 2006
not be as useful as we might hope. Consider the case of an ISP that
offers each of its customers only a single NAT address. This ISP
could instead have chosen to provide each customer with a single
public IP address, or, if the ISP insists on running NAT, it could
have chosen to allow each customer a reasonable number of addresses,
enough for each customer device to have its own NAT address directly
from the ISP. If instead this ISP chooses to allow each customer
just one and only one NAT address, forcing said customer to run
nested NAT in order to use more than one device, it seems unlikely
that such an ISP would be so obliging as to provide a NAT service
that supports NAT Port Mapping Protocol. Supposing that such an ISP
did wish to offer its customers NAT service with NAT-PMP so as to
give them the ability to receive inbound connections, this ISP could
easily choose to allow each client to request a reasonable number of
DHCP addresses from that gateway. Remember that Net 10/8 [RFC 1918]
allows for over 16 million addresses, so NAT addresses are not in any
way in short supply. A single NAT gateway with 16 million available
addresses is likely to run out of packet forwarding capacity before
it runs out of private addresses to hand out. In this way the ISP
could offer single-level NAT with NAT-PMP, obviating the need to
support nested NAT-PMP. In addition, an ISP that is motivated to
provide their customers with unhindered access to the Internet by
allowing incoming as well as outgoing connections has better ways
to offer this service. Such an ISP could offer its customers real
public IP addresses instead of NAT addresses, or could even choose
to offer its customers full IPv6 connectivity, where no mapping or
translation is required at all.
4.3.2 NATs with Multiple Public IP Addresses
If a NAT maps private addresses to multiple public addresses,
then it SHOULD pick one of those addresses as the one it will
support for inbound connections, and for the purposes of this
protocol it SHOULD act as if that address were its only address.
4.3.3 NATs and Routed Private Networks
In some cases, a large network may be subnetted. Some sites
may install a NAT gateway and subnet the private network.
Such subnetting breaks this protocol because the router address
is not necessarily the address of the device performing NAT.
Addressing this problem is not a high priority. Any site with the
resources to set up such a configuration should have the resources to
add manual mappings or attain a range of globally unique addresses.
Not all NATs will support this protocol. In the case where a client
is run behind a NAT that does not support this protocol, the software
relying on the functionality of this protocol may be unusable.
Expires 14th March 2007 Cheshire, et al. [Page 15]
Internet Draft NAT Port Mapping Protocol 14th September 2006
4.3.4 Communication Between Hosts Behind the Same NAT
NAT gateways supporting NAT-PMP should also implement "hairpin
translation". Hairpin translation means supporting communication
between two local clients being served by the same NAT gateway.
Suppose device A is listening on private address and port 10.0.0.2:80
for incoming connections. Using NAT-PMP, device A has obtained a
mapping to public address and port x.x.x.x:80, and has recorded this
public address and port in a public directory of some kind. For
example, it could have created a DNS SRV record containing this
information, and recorded it, using DNS Dynamic Update [RFC 3007], in
a publicly accessible DNS server. Suppose then that device B, behind
the same NAT gateway as device A, but unknowing or uncaring of this
fact, retrieves device A's DNS SRV record and attempts to open a TCP
connection to x.x.x.x:80. The outgoing packets addressed to this
public Internet address will be sent to the NAT gateway for
translation and forwarding. Having translated the source address and
port number on the outgoing packet, the NAT gateway needs to be smart
enough to recognize that the destination address is in fact itself,
and then feed this packet back into its packet reception engine, to
perform the destination port mapping lookup to translate and forward
this packet to device A at address and port 10.0.0.2:80.
4.3.5 Non UDP/TCP Transport Traffic
Any communication over transport protocols other than TCP and UDP
will not be served by this protocol. Examples are Generic Routing
Encapsulation (GRE), Authentication Header (AH) and Encapsulating
Security Payload (ESP).
4.4 Long Term Solution
As IPv6 is deployed, clients of this protocol supporting IPv6 will be
able to bypass this protocol and the NAT when communicating with
other IPv6 devices. In order to ensure this transition, any client
implementing this protocol SHOULD also implement IPv6 and use this
solution only when IPv6 is not available to both peers.
4.5 Existing Deployed NATs
Existing deployed NATs will not support this protocol. This protocol
will only work with NATs that are upgraded to support it.
Expires 14th March 2007 Cheshire, et al. [Page 16]
Internet Draft NAT Port Mapping Protocol 14th September 2006
5. Security Considerations
As discussed in section 3.2 "Determining the Public Address", only
clients on the private side of the NAT may create port mappings, and
only on behalf of themselves. By using IP address spoofing, it's
possible for one client to delete the port mappings of another
client. It's also possible for one client to create port mappings on
behalf of another client. The best way to deal with this
vulnerability is to use IPSec [RFC 2401].
Since allowing incoming connections is often a policy decision, any
NAT gateway implementing this protocol SHOULD have an administrative
mechanism to disable it.
Some people view the property that NATs block inbound connections as
a security benefit which is undermined by this protocol. The authors
of this document have a different point of view. In the days before
NAT, all hosts had unique public IP addresses, and had unhindered
ability to communicate with any other host on the Internet. When NAT
came along it broke this unhindered connectivity, relegating many
hosts to second-class status, unable to receive inbound connections.
This protocol goes some way to undo some of that damage. The purpose
of a NAT gateway should be to allow several hosts to share a single
address, not to simultaneously impede those host's ability to
communicate freely. Security is most properly provided by end-to-end
cryptographic security, and/or by explicit firewall functionality, as
appropriate. Blocking of certain connections should occur only as a
result of explicit and intentional firewall policy, not as an
accidental side-effect of some other technology.
6. IANA Considerations
No IANA services are required by this document.
7. Acknowledgments
The concepts described in this document have been explored, developed
and implemented with help from Bob Bradley, Josh Graessley, Rob
Newberry, Roger Pantos, John Saxton, and James Woodyatt.
8. Deployment History
NAT-PMP client software first became available to the public
through Apple's Darwin Open Source code in August 2004.
NAT-PMP implementations began shipping to end users in large
volumes (i.e. millions) with the launch of Mac OS X 10.4 Tiger
and Bonjour for Windows 1.0 in April 2005.
Expires 14th March 2007 Cheshire, et al. [Page 17]
Internet Draft NAT Port Mapping Protocol 14th September 2006
The NAT-PMP client in Mac OS X 10.4 Tiger and Bonjour for Windows
exists as part of the mDNSResponder system service. When a client
advertises a service using Wide Area Bonjour [DNS-SD], and the
machine is behind a NAT-PMP-capable NAT gateway, then if the machine
is so configured, the mDNSResponder system service automatically uses
NAT-PMP to set up an inbound port mapping, and then records the
public IP address and port in the global DNS. Existing client
software using the existing Bonjour programming APIs [Bonjour]
gets this functionality automatically. The logic is that if client
software publishes its information into the global DNS via Wide Area
Bonjour service advertising, then it's reasonable to infer an
expectation that this information should be usable by the peers
retrieving it. Generally speaking, recording a private IP address
like 10.0.0.2 in the public DNS is completely pointless because that
address is not reachable from clients on the other side of the NAT
gateway. In the case of a home user with a single computer directly
connected to their Cable or DSL modem, with a single global IPv4
address and no NAT gateway (a surprisingly common configuration),
publishing that IP address into the global DNS is useful because that
IP address is reachable. In contrast, a home user using a NAT gateway
to share a single global IPv4 address between several computers loses
this ability to receive inbound connections easily. This breaks many
peer-to-peer collaborative applications, like the multi-user text
editor SubEthaEdit [SEE]. Automatically creating the necessary
inbound port mappings helps remedy this unintended side-effect of
NAT.
The server side of the NAT-PMP protocol is implemented in Apple's
"AirPort Extreme" and "AirPort Express" wireless base stations.
9. Copyright Notice
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights. For the purposes of this document,
the term "BCP 78" refers exclusively to RFC 3978, "IETF Rights
in Contributions", published March 2005.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires 14th March 2007 Cheshire, et al. [Page 18]
Internet Draft NAT Port Mapping Protocol 14th September 2006
10. Normative References
[RFC 1918] Y. Rekhter et.al., "Address Allocation for Private
Internets", RFC 1918, February 1996.
[RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate
Requirement Levels
11. Informative References
[Bonjour] Apple "Bonjour" <http://developer.apple.com/bonjour/>
[ETEAISD] J. Saltzer, D. Reed and D. Clark: "End-to-end arguments in
system design", ACM Trans. Comp. Sys., 2(4):277-88, Nov.
1984
[DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
Discovery", Internet-Draft (work in progress),
draft-cheshire-dnsext-dns-sd-04.txt, August 2006.
[mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
Internet-Draft (work in progress),
draft-cheshire-dnsext-multicastdns-06.txt, August 2006.
[RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC 2401] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC 3007] Wellington, B., "Simple Secure Domain Name System
(DNS) Dynamic Update", RFC 3007, November 2000.
[SEE] <http://www.codingmonkeys.de/subethaedit/>
[RFC 3022] RFC 3022 - Network Address Translator
[RFC 3424] RFC 3424 - IAB Considerations for UNilateral Self-Address
Fixing (UNSAF) Across Network Address Translation
Expires 14th March 2007 Cheshire, et al. [Page 19]
Internet Draft NAT Port Mapping Protocol 14th September 2006
12. Authors' Addresses
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc [at] stuartcheshire [dot] org
Marc Krochmal
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 4368
EMail: marc [at] apple [dot] com
Kiren Sekar
Sharpcast, Inc.
250 Cambridge Ave, Suite 101
Palo Alto
California 94306
USA
Phone: +1 650 323 1960
EMail: ksekar [at] sharpcast [dot] com
Expires 14th March 2007 Cheshire, et al. [Page 20]
|