idnits 2.17.1
draft-ietf-behave-sctpnat-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([RFC0793], [RFC4960]), which
it shouldn't. Please replace those with straight textual mentions of the
documents in question.
== There are 28 instances of lines with non-RFC6890-compliant IPv4
addresses in the document. If these are example addresses, they should
be changed.
== There are 37 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 9, 2012) is 4210 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'Initiate-Tag' is mentioned on line 376, but not
defined
** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293)
** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260)
-- Obsolete informational reference (is this intentional?): RFC 5735
(Obsoleted by RFC 6890)
== Outdated reference: A later version (-23) exists of
draft-ietf-tsvwg-natsupp-02
Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group R. Stewart
3 Internet-Draft Adara Networks
4 Intended status: BCP M. Tuexen
5 Expires: April 12, 2013 I. Ruengeler
6 Muenster Univ. of Appl. Sciences
7 October 9, 2012
9 Stream Control Transmission Protocol (SCTP) Network Address Translation
10 draft-ietf-behave-sctpnat-07.txt
12 Abstract
14 Stream Control Transmission Protocol [RFC4960] provides a reliable
15 communications channel between two end-hosts in many ways similar to
16 TCP [RFC0793]. With the widespread deployment of Network Address
17 Translators (NAT), specialized code has been added to NAT for TCP
18 that allows multiple hosts to reside behind a NAT and yet use only a
19 single globally unique IPv4 address, even when two hosts (behind a
20 NAT) choose the same port numbers for their connection. This
21 additional code is sometimes classified as Network Address and Port
22 Translation or NAPT. To date, specialized code for SCTP has NOT yet
23 been added to most NATs so that only pure NAT is available. The end
24 result of this is that only one SCTP capable host can be behind a
25 NAT.
27 This document describes an SCTP specific variant of NAT which
28 provides similar features of NAPT in the single point and multi-point
29 traversal scenario.
31 Status of this Memo
33 This Internet-Draft is submitted in full conformance with the
34 provisions of BCP 78 and BCP 79.
36 Internet-Drafts are working documents of the Internet Engineering
37 Task Force (IETF). Note that other groups may also distribute
38 working documents as Internet-Drafts. The list of current Internet-
39 Drafts is at http://datatracker.ietf.org/drafts/current/.
41 Internet-Drafts are draft documents valid for a maximum of six months
42 and may be updated, replaced, or obsoleted by other documents at any
43 time. It is inappropriate to use Internet-Drafts as reference
44 material or to cite them other than as "work in progress."
46 This Internet-Draft will expire on April 12, 2013.
48 Copyright Notice
49 Copyright (c) 2012 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (http://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 4. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . . . . 4
68 4.1. Single Point Traversal . . . . . . . . . . . . . . . . . . 4
69 4.2. Multi Point Traversal . . . . . . . . . . . . . . . . . . 5
70 5. Limitations of Classical NAPT for SCTP . . . . . . . . . . . . 6
71 6. The SCTP Specific Variant of NAT . . . . . . . . . . . . . . . 6
72 7. NAT to SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 11
73 8. Handling of Fragmented SCTP Packets . . . . . . . . . . . . . 11
74 9. Various Examples of NAT Traversals . . . . . . . . . . . . . . 11
75 9.1. Single-homed Client to Single-homed Server . . . . . . . . 11
76 9.2. Single-homed Client to Multi-homed Server . . . . . . . . 13
77 9.3. Multihomed Client and Server . . . . . . . . . . . . . . . 15
78 9.4. NAT Loses Its State . . . . . . . . . . . . . . . . . . . 19
79 9.5. Peer-to-Peer Communication . . . . . . . . . . . . . . . . 21
80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
82 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
85 13.2. Informative References . . . . . . . . . . . . . . . . . . 26
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
88 1. Introduction
90 Stream Control Transmission Protocol [RFC4960] provides a reliable
91 communications channel between two end-hosts in many ways similar to
92 TCP [RFC0793]. With the widespread deployment of Network Address
93 Translators (NAT), specialized code has been added to NAT for TCP
94 that allows multiple hosts to reside behind a NAT and use private
95 addresses (see [RFC5735]) and yet use only a single globally unique
96 IPv4 address, even when two hosts (behind a NAT) choose the same port
97 numbers for their connection. This additional code is sometimes
98 classified as Network Address and Port Translation or NAPT. To date,
99 specialized code for SCTP has not yet been added to most NATs so that
100 only true NAT is available. The end result of this is that only one
101 SCTP capable host can be behind a NAT.
103 This document proposes an SCTP specific variant NAT that provides the
104 NAPT functionality without changing SCTP port numbers. The authors
105 feel it is possible and desirable to make these changes for a number
106 of reasons.
108 o It is desirable for SCTP internal end-hosts on multiple platforms
109 to be able to share a NAT's public IP address, much as TCP does
110 today.
112 o If a NAT does not need to change any data within an SCTP packet it
113 will reduce the processing burden of NAT'ing SCTP by NOT needing
114 to execute the CRC32c checksum required by SCTP.
116 o Not having to touch the IP payload makes the processing of ICMP
117 messages in NATs easier.
119 2. Conventions
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in [RFC2119].
125 3. Terminology
127 For this discussion we will use several terms, which we will define
128 and point out in Figure 1.
130 Private-Address (Priv-Addr): The private address that is known to
131 the internal host.
133 Internal-Port (Int-Port): The port number that is in use by the host
134 holding the Private-Address.
136 Internal-VTag (Int-VTag): The Verification Tag that the internal
137 host has chosen for its communication. The VTag is a unique 32
138 bit tag that must accompany any incoming SCTP packet for this
139 association to the Private-Address.
141 External-Address (Ext-Addr): The address that an internal host is
142 attempting to contact.
144 External-Port (Ext-Port): The port number of the peer process at the
145 External-Address.
147 External-VTag (Ext-VTag): The Verification Tag that the host holding
148 the External-Address has chosen for its communication. The VTag
149 is a unique 32 bit tag that must accompany any incoming SCTP
150 packet for this association to the External-Address.
152 Public-Address (Pub-Addr): The public address assigned to the NAT
153 box which it uses as a source address when sending packets towards
154 the External-Address.
156 Internal Network | External Network
157 |
158 Private | Public External
159 +---------+ Address | Address /--\/--\ Address +---------+
160 | SCTP | +-----+ / \ | SCTP |
161 |end point|==========| NAT |======= | Internet | ======== |end point|
162 | A | +-----+ \ / | B |
163 +---------+ Internal | \--/\--/ External +---------+
164 Internal Port | Port External
165 VTag | VTag
167 Figure 1: Architecture
169 4. SCTP NAT Traversal Scenarios
171 This section defines the notion of single and multi-point NAT
172 traversal.
174 4.1. Single Point Traversal
176 In this case, all packets in the SCTP association go through a single
177 NAT, as shown below:
179 Internal Network | External Network
180 |
181 +---------+ | /--\/--\ +---------+
182 | SCTP | +-----+ / \ | SCTP |
183 |end point|=========| NAT |========= | Internet | ========|end point|
184 | A | +-----+ \ / | B |
185 +---------+ | \--/\--/ +---------+
186 |
188 Single NAT scenario
190 A variation of this case is shown below, i.e., multiple NATs in a
191 single path:
193 Internal | External : Internal | External
194 | : |
195 +---------+ | : | /--\/--\ +---------+
196 | SCTP | +-----+ : +-----+ / \ | SCTP |
197 |end point|==| NAT |=======:=======| NAT |==| Internet |==|end point|
198 | A | +-----+ : +-----+ \ / | B |
199 +---------+ | : | \--/\--/ +---------+
200 | : |
202 Serial NATs scenario
204 In this single point traversal scenario, we must acknowledge that
205 while one of the main benefits of SCTP multi-homing is redundant
206 paths, the NAT function represents a single point of failure in the
207 path of the SCTP multi-home association. However, the rest of the
208 path may still benefit from path diversity provided by SCTP multi-
209 homing.
211 The two SCTP endpoints in this case can be either single-homed or
212 multi-homed. However, the important thing is that the NAT (or NATs)
213 in this case sees all the packets of the SCTP association.
215 4.2. Multi Point Traversal
217 This case involves multiple NATs and each NAT only sees some of the
218 packets in the SCTP association. An example is shown below:
220 Internal | External
221 +------+ /---\/---\
222 +---------+ /=======|NAT A |=========\ / \ +---------+
223 | SCTP | / +------+ \/ \ | SCTP |
224 |end point|/ ... | Internet |===|end point|
225 | A |\ \ / | B |
226 +---------+ \ +------+ / \ / +---------+
227 \=======|NAT B |=========/ \---\/---/
228 +------+
229 |
231 Parallel NATs scenario
233 This case does NOT apply to a single-homed SCTP association (i.e.,
234 BOTH endpoints in the association use only one IP address). The
235 advantage here is that the existence of multiple NAT traversal points
236 can preserve the path diversity of a multi-homed association for the
237 entire path. This in turn can improve the robustness of the
238 communication.
240 5. Limitations of Classical NAPT for SCTP
242 Using classical NAPT may result in changing one of the SCTP port
243 numbers during the processing which requires the recomputation of the
244 transport layer checksum. Whereas for UDP and TCP this can be done
245 very efficiently, for SCTP the checksum (CRC32c) over the entire
246 packet needs to be recomputed. This would add considerable to the
247 NAT computational burden, however hardware support may mitigate this
248 in some implementations.
250 An SCTP endpoint may have multiple addresses but only has a single
251 port number. To make multipoint traversal work, all the NATs
252 involved must recognize the packets they see as belonging to the same
253 SCTP association and perform port number translation in a consistent
254 way. One possible way of doing this is to use pre-defined table of
255 ports and addresses configured within each NAT. Other mechanisms
256 could make use of NAT to NAT communication. Such mechanisms are
257 considered by the authors not to be deployable on a wide scale base
258 and thus not a recommended solution. Therefore the SCTP variant of
259 NAT has been developed.
261 6. The SCTP Specific Variant of NAT
263 In this section we assume that we have multiple SCTP capable hosts
264 behind a NAT which has one Public-Address. Furthermore we are
265 focusing in this section on the single point traversal scenario.
267 The modification of SCTP packets sent to the public Internet is easy.
268 The source address of the packet has to be replaced with the Public-
269 Address. It may also be necessary to establish some state in the NAT
270 box to handle incoming packets, which is discussed later.
272 For SCTP packets coming from the public Internet the destination
273 address of the packets has to be replaced with the Private-Address of
274 the host the packet has to be delivered to. The lookup of the
275 Private-Address is based on the External-VTag, External-Port,
276 External-Address, Internal-VTag and the Internal-Port.
278 For the SCTP NAT processing the NAT box has to maintain a table of
279 Internal-VTag, Internal-Port, Private-Address, External-VTag,
280 External-Port and whether the restart procedure is disabled or not.
281 An entry in that table is called a NAT state control block. The
282 function Create() obtains the just mentioned parameters and returns a
283 NAT-State control block.
285 The entries in this table fulfill some uniqueness conditions. There
286 must not be more than one entry with the same pair of Internal-Port
287 and External-Port. This rule can be relaxed, if all entries with the
288 same Internal-Port and External-Port have the support for the restart
289 procedure enabled. In this case there must be no more than one entry
290 with the same Internal-Port, External-Port and Ext-VTag and no more
291 than one entry with the same Internal-Port, External-Port and Int-
292 VTag.
294 The processing of outgoing SCTP packets containing an INIT-chunk is
295 described in the following figure. The scenario shown is valid for
296 all message flows in this section.
298 /--\/--\
299 +--------+ +-----+ / \ +--------+
300 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
301 +--------+ +-----+ \ / +--------+
302 \--/\---/
304 INIT[Initiate-Tag]
305 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port
306 Ext-VTag=0
308 Create(Initiate-Tag, Int-Port, Priv-Addr, 0)
309 Returns(NAT-State control block)
311 Translate To:
313 INIT[Initiate-Tag]
314 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port
315 Ext-VTag=0
317 It should be noted that normally a NAT control block will be created.
318 However, it is possible that there is already a NAT control block
319 with the same External-Address, External-Port, Internal-Port, and
320 Internal-VTag but different Private-Address. In this case the INIT
321 SHOULD be dropped by the NAT and an ABORT SHOULD be sent back to the
322 SCTP host with the M-Bit set and an appropriate error cause (see
323 [I-D.ietf-tsvwg-natsupp] for the format).
325 It is also possible that a connection to External-Address and
326 External-Port exists without an Internal-VTag conflict but the
327 External-Address does not support the DISABLE_RESTART feature (noted
328 in the NAT control block when the prior connection was established).
329 In such a case the INIT SHOULD be dropped by the NAT and an ABORT
330 SHOULD be sent back to the SCTP host with the M-Bit set and an
331 appropriate error cause (see [I-D.ietf-tsvwg-natsupp] for the
332 format).
334 The processing of outgoing SCTP packets containing no INIT-chunk is
335 described in the following figure.
337 /--\/--\
338 +--------+ +-----+ / \ +--------+
339 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
340 +--------+ +-----+ \ / +--------+
341 \--/\---/
343 Priv-Addr:Int-Port ------> Ext-Addr:Ext-Port
344 Ext-VTag
346 Translate To:
348 Pub-Addr:Int-Port ------> Ext-Addr:Ext-Port
349 Ext-VTag
351 The processing of incoming SCTP packets containing INIT-ACK chunks is
352 described in the following figure. The Lookup() function getting as
353 input the Internal-VTag, Internal-Port, External-VTag (=0), External-
354 Port, and External-Address, returns the corresponding entry of the
355 NAT table and updates the External-VTag by substituting it with the
356 value of the Initiate-Tag of the INIT-ACK chunk. The wildcard
357 character signifies that the parameter's value is not considered in
358 the Lookup() function or changed in the Update() function,
359 respectively.
361 /--\/--\
362 +--------+ +-----+ / \ +--------+
363 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
364 +--------+ +-----+ \ / +--------+
365 \--/\---/
367 INIT-ACK[Initiate-Tag]
368 Pub-Addr:Int-Port <---- Ext-Addr:Ext-Port
369 Int-VTag
371 Lookup(Int-VTag, Int-Port, *, 0, Ext-Port)
372 Update(*, *, *, Initiate-Tag, *)
374 Returns(NAT-State control block containing Private-Address)
376 INIT-ACK[Initiate-Tag]
377 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port
378 Int-VTag
380 In the case Lookup fails, the SCTP packet is dropped. The Update
381 routine inserts the External-VTag (the Initiate-Tag of the INIT-ACK
382 chunk) in the NAT state control block.
384 The processing of incoming SCTP packets containing an ABORT or
385 SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the
386 following figure.
388 /--\/--\
389 +--------+ +-----+ / \ +--------+
390 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
391 +--------+ +-----+ \ / +--------+
392 \--/\---/
394 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port
395 Ext-VTag
397 Lookup(0, Int-Port, *, Ext-VTag, Ext-Port)
399 Returns(NAT-State control block containing Private-Address)
401 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port
402 Ext-VTag
404 The processing of other incoming SCTP packets is described in the
405 following figure.
407 /--\/--\
408 +--------+ +-----+ / \ +--------+
409 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
410 +--------+ +-----+ \ / +--------+
411 \--/\---/
413 Pub-Addr:Int-Port <------ Ext-Addr:Ext-Port
414 Int-VTag
416 Lookup(Int-VTag, Int-Port, *, *, Ext-Port)
418 Returns(NAT-State control block containing Local-Address)
420 Priv-Addr:Int-Port <------ Ext-Addr:Ext-Port
421 Int-VTag
423 For an incoming packet containing an INIT-chunk a table lookup is
424 made only based on the addresses and port numbers. If an entry with
425 an External-VTag of zero is found, it is considered a match and the
426 External-VTag is updated.
428 This allows the handling of INIT-collision through NAT.
430 7. NAT to SCTP
432 This document at various places discusses the sending of specialized
433 SCTP chunks (e.g. an ABORT with M-Bit set). These chunks and
434 procedures are not defined in this document, but instead are defined
435 in [I-D.ietf-tsvwg-natsupp]. The NAT implementer should refer to
436 [I-D.ietf-tsvwg-natsupp] for detailed descriptions of packet formats
437 and procedures.
439 8. Handling of Fragmented SCTP Packets
441 A NAT box MUST support IP reassembly of received fragmented SCTP
442 packets. The fragments may arrive in any order.
444 When an SCTP packet has to be fragmented by the NAT box and the IP
445 header forbids fragmentation a corresponding ICMP packet SHOULD be
446 sent.
448 9. Various Examples of NAT Traversals
450 9.1. Single-homed Client to Single-homed Server
452 The internal client starts the association with the external server
453 via a four-way-handshake. Host A starts by sending an INIT chunk.
455 /--\/--\
456 +--------+ +-----+ / \ +--------+
457 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
458 +--------+ +-----+ \ / +--------+
459 \--/\---/
460 +---------+--------+-----------+----------+--------+
461 NAT | Int | Int | Priv | Ext | Ext |
462 | VTag | Port | Addr | VTag | Port |
463 +---------+--------+--- -------+----------+--------+
465 INIT[Initiate-Tag = 1234]
466 10.0.0.1:1 ------> 100.0.0.1:2
467 Ext-VTtag = 0
469 A NAT entry is created, the source address is substituted and the
470 packet is sent on:
472 NAT creates entry:
473 +---------+--------+-----------+----------+--------+
474 NAT | Int | Int | Priv | Ext | Ext |
475 | VTag | Port | Addr | VTag | Port |
476 +---------+--------+-----------+----------+--------+
477 | 1234 | 1 | 10.0.0.1 | 0 | 2 |
478 +---------+--------+-----------+----------+--------+
480 INIT[Initiate-Tag = 1234]
481 101.0.0.1:1 --------------------------> 100.0.0.1:2
482 Ext-VTtag = 0
484 Host B receives the INIT and sends an INIT-ACK with the NAT's
485 external address as destination address.
487 /--\/--\
488 +--------+ +-----+ / \ +--------+
489 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
490 +--------+ +-----+ \ / +--------+
491 \--/\---/
493 INIT-ACK[Initiate-Tag = 5678]
494 101.0.0.1:1 <------------------------- 100.0.0.1:2
495 Int-VTag = 1234
497 NAT updates entry:
498 +---------+--------+-----------+----------+--------+
499 NAT | Int | Int | Priv | Ext | Ext |
500 | VTag | Port | Addr | VTag | Port |
501 +---------+--------+-----------+----------+--------+
502 | 1234 | 1 | 10.0.0.1 | 5678 | 2 |
503 +---------+--------+-----------+----------+--------+
505 INIT-ACK[Initiate-Tag = 5678]
506 10.0.0.1:1 <------ 100.0.0.1:2
507 Int-VTag = 1234
509 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE-
510 ACK.
512 /--\/--\
513 +--------+ +-----+ / \ +--------+
514 | Host A | <------> | NAT | <------> | Internet | <------> | Host B |
515 +--------+ +-----+ \ / +--------+
516 \--/\---/
518 COOKIE-ECHO
519 10.0.0.1:1 ------> 100.0.0.1:2
520 Ext-VTag = 5678
522 COOKIE-ECHO
523 101.0.0.1:1 -------------------------> 100.0.0.1:2
524 Ext-VTag = 5678
526 COOKIE-ACK
527 101.0.0.1:1 <------------------------- 100.0.0.1:2
528 Int-VTag = 1234
530 COOKIE-ACK
531 10.0.0.1:1 <------ 100.0.0.1:2
532 Int-VTag = 1234
534 9.2. Single-homed Client to Multi-homed Server
536 The internal client is single-homed whereas the external server is
537 multi-homed. The client (Host A) sends an INIT like in the single-
538 homed case.
540 +--------+
541 /--\/--\ /-|Router 1| \
542 +------+ +-----+ / \ / +--------+ \ +------+
543 | Host | <-----> | NAT | <-> | Internet | == =| Host |
544 | A | +-----+ \ / \ +--------+ / | B |
545 +------+ \--/\--/ \-|Router 2|-/ +------+
546 +--------+
548 +---------+--------+-----------+----------+--------+
549 NAT | Int | Int | Priv | Ext | Ext |
550 | VTag | Port | Addr | VTag | Port |
551 +---------+--------+-----------+----------+--------+
553 INIT[Initiate-Tag = 1234]
554 10.0.0.1:1 ---> 100.0.0.1:2
555 Ext-VTag = 0
557 NAT creates entry:
559 +---------+--------+-----------+----------+--------+
560 NAT | Int | Int | Priv | Ext | Ext |
561 | VTag | Port | Addr | VTag | Port |
562 +---------+--------+-----------+----------+--------+
563 | 1234 | 1 | 10.0.0.1 | 0 | 2 |
564 +---------+--------+-----------+----------+--------+
566 INIT[Initiate-Tag = 1234]
567 101.0.0.1:1 ----------------------------> 100.0.0.1:2
568 Ext-VTag = 0
570 The server (Host B) includes its two addresses in the INIT-ACK chunk,
571 which results in two NAT entries.
573 +--------+
574 /--\/--\ /-|Router 1| \
575 +------+ +-----+ / \ / +--------+ \ +------+
576 | Host | <-----> | NAT | <-> | Internet | == =| Host |
577 | A | +-----+ \ / \ +--------+ / | B |
578 +------+ \--/\--/ \-|Router 2|-/ +------+
579 +--------+
581 INIT-ACK[Initiate-tag = 5678, IP-Addr = 100.1.0.1]
582 101.0.0.1:1 <---------------------------- 100.0.0.1:2
583 Int-VTag = 1234
585 NAT does need to change the table for second address:
587 +---------+--------+-----------+----------+--------+
588 NAT | Int | Int | Priv | Ext | Ext |
589 | VTag | Port | Addr | VTag | Port |
590 +---------+--------+-----------+----------+--------+
591 | 1234 | 1 | 10.0.0.1 | 5678 | 2 |
592 +---------+--------+-----------+----------+--------+
594 INIT-ACK[Initiate-Tag = 5678]
595 10.0.0.1:1 <--- 100.0.0.1:2
596 Int-VTag = 1234
598 The handshake finishes with a COOKIE-ECHO acknowledged by a COOKIE-
599 ACK.
601 +--------+
602 /--\/--\ /-|Router 1| \
603 +------+ +-----+ / \ / +--------+ \ +------+
604 | Host | <-----> | NAT | <-> | Internet | == =| Host |
605 | A | +-----+ \ / \ +--------+ / | B |
606 +------+ \--/\--/ \-|Router 2|-/ +------+
607 +--------+
609 COOKIE-ECHO
610 10.0.0.1:1 ---> 100.0.0.1:2
611 ExtVTag = 5678
613 COOKIE-ECHO
614 101.0.0.1:1 ----------------------------> 100.0.0.1:2
615 Ext-VTag = 5678
617 COOKIE-ACK
618 101.0.0.1:1 <---------------------------- 100.0.0.1:2
619 Int-VTag = 1234
621 COOKIE-ACK
622 10.0.0.1:1 <--- 100.0.0.1:2
623 Int-VTag = 1234
625 9.3. Multihomed Client and Server
627 The client (Host A) sends an INIT to the server (Host B), but does
628 not include the second address.
630 +-------+
631 /--| NAT 1 |--\ /--\/--\
632 +------+ / +-------+ \ / \ +--------+
633 | Host |=== ====| Internet |====| Host B |
634 | A | \ +-------+ / \ / +--------+
635 +------+ \--| NAT 2 |--/ \--/\--/
636 +-------+
638 +---------+--------+-----------+----------+--------+
639 NAT 1 | Int | Int | Priv | Ext | Ext |
640 | VTag | Port | Addr | VTag | Port |
641 +---------+--------+--- -------+----------+--------+
643 INIT[Initiate-Tag = 1234]
644 10.0.0.1:1 --------> 100.0.0.1:2
645 Ext-VTag = 0
646
647
648 NAT 1 creates entry:
649