Assignment 2 Koustubh Arpit

ANSWER 1

(a)

(b)

Packets- 3, 4, 6, 7, 8

Packet Delay

2 7

3 9

4 8

5 7

6 9

7 8

8 8

(c)

Packets -3, 6

(d)

Minimum delay= 2 units of time.

ANSWER 2

(a)

di = (1- u)di-1 + u(ri - ti)

U=0.1

Packet Estimated delay for packets

2 1.33

3 2.097

4 2.687

5 3.119

6 3.707

7 4.136

8 4.662

(b)

vi = (1- u)vi-1 + u(ri - ti - di)

U=0.1

Packet Estimated deviation of

delay from estimated avg

2 1.23

3 1.7073

4 2.0678

5 2.2492

6 2.5536

7 2.6846

8 2.7539

ANSWER 3

(e)

For the address 2819:00AF:0000:0000:0000:0035:0CB2:B271;

Sr.No Question After Abbreviation

(a) 0000:0000:0F53:6382:AB00:67DB:BB27:7332 ::F53:6382:AB00:67DB:BB27:7332

(b) 0000:0000:0000:0000:0000:0000:004D:ABCD ::4D:ABCD

(c) 0000:0000:0000:AF36:7328:0000:87AA:0398 ::AF36:7328:0:87AA:398

(d) 2819:00AF:0000:0000:0000:0035:0CB2:B271 2819:AF::35:CB2:B271

Name Address After Abbreviation

Link-Local FE80:0000:0000:0000:0000:0035:0CB2:B271

FE80::35:CB2:B271

Unique Local FC00:0000:0000:0000:0000:0035:0CB2:B271 FC00::35:CB2:B271

Node Multicast IPv6

FF02:0000:0000:0000:0000:0001:FFB2:B271 FF02::1:FFB2:B271

ANSWER 4

(a)

Scenarios Message

type

Code ICMPv6 error message

Router drops a packet as the

size is too big

2 0

Router drops a packet

because of a prohibiting

policy.

1 1 communication with destination

administratively prohibited

The IPv6 layer of a host

receives an IP packet for a

non-existing process.

1 4 port unreachable

(b)

Scenarios DHCPv6 messages required for the following

The client wants to obtain two temporary IP addresses ::8080 and ::8090 from the

DHCP server

DHCPv6 message – DHCPREQUEST Message type: Request (3) Transaction-ID: 0x0086a342 Client Identifier option type: 1 option length: 14 DUID type: link-layer address plus time (1) Hardware type: Ethernet (1) Time: 281507745 Link-layer address: 00:16:3e:18:88:fe Server Identifier option type: 2 option length: 14 DUID type: link-layer address plus time (1) Hardware type: Ethernet (1) Time: 281498447 Link-layer address: 00:16:3e:60:6d:5d Option Request option type: 6 option length: 4 Requested Option code: DNS recursive name

server (23) Requested Option code: Domain Search List (24) Elapsed time option type: 8 option length: 2 elapsed-time: 0 ms Identity Association for Non-temporary Address option type: 3 option length: 40 IAID: 1041795326 T1: 3600 T2: 5400 IA Address option type: 5 option length: 24 IPv6 address: 2001:558:ff10:870:f914:a7c1:42d1:faa1 Preferred lifetime: 7200 Valid lifetime: 7500

The server wants to reconfigure all the clients with the IPv6 network prefix

2001:30:42::/48

DHCPv6 message - DHCPFORCERENEW Message type: Reconfigure (10) Transaction-ID: 0x00000000 Client Identifier option type: 1 option length: 14 DUID type: link-layer address plus time (1) Hardware type: IEEE 802 (6) Time: 1414087501 Link-layer address: 00:15:a4:a5:a4:68 Server Identifier option type: 2 option length: 14 DUID type: link-layer address plus time (1) Hardware type: Ethernet (1) Time: 261780576 Link-layer address: 00:03:ba:90:fb:61 Reconfigure Message option type: 19 option length: 1 Reconfigure-type: Renew Authentication option type: 11 option length: 28 Protocol: 3 Algorithm: 1 RDM: 0 Replay Detection Authentication Information

ANSWER 5

(a)

In the context of computer networks, the signal is generally a data packet, and the RTT is also known as the ping

time. An internet user can determine the RTT by using the PING command.

We use PING from the CMD Window.

It gives us the following:-

Type of RTT In Units of milliseconds

Minimum 0

Maximum 8

Average 2

(b)

Using traceroute tool at: http://support.deldsl.net/cgi-bin/trace/chaseroute.pl. Tracing route to 8.8.8.8. [8.8.8.8] Over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms ptr-203-110-87-17.deldsl.net [203.110.87.17] 2 <1 ms <1 ms <1 ms ptr-203-110-80-9.deldsl.net [203.110.80.9] 3 2 ms 2 ms 2 ms 115.113.254.77.static-delhi.vsnl.net.in [115.113.254.77] 4 44 ms 44 ms 43 ms 172.31.17.5 5 43 ms 42 ms 43 ms 121.240.1.46 6 46 ms 46 ms 46 ms 209.85.241.21 7 47 ms 47 ms 46 ms google-public-dns-a.google.com [8.8.8.8] Trace complete.

(c)

Network-Tools Traceroute Results :

Network-Tools Traceroute Results [Clear]:

traceroute to 49.248.160.149 (49.248.160.149), 30 hops max, 40 byte packets 1 vserver155.hostnoc.net (64.120.200.186) 0.073 ms 0.019 ms 0.017 ms 2 ec0-61.agg04.sctn01.hostnoc.net (96.9.184.62) 0.858 ms 0.832 ms 0.809 ms 3 xe1-04.gwy02.sctn01.hostnoc.net (96.9.191.13) 0.777 ms 0.755 ms 0.730 ms 4 TenGE2-1.br02.phl02.pccwbtn.net (63.218.31.41) 5.675 ms 6.643 ms 6.618 ms 5 gblx.ge12-4.br02.ash01.pccwbtn.net (63.218.94.214) 10.583 ms 10.558 ms 11.522 ms 6 te3-2-10G.ar5.DCA3.gblx.net (67.16.139.66) 8.498 ms 8.471 ms 8.446 ms 7 teleglobe-1.ar5.dca3.gblx.net (64.215.195.82) 9.405 ms 8.967 ms 9.956 ms 8 if-3-2.tcore2.NJY-Newark.as6453.net (216.6.87.10) 216.812 ms if-10-2.tcore1.L78-London.as6453.net (216.6.87.105) 204.794 ms 206.757 ms 9 if-6-2.tcore2.MLV-Mumbai.as6453.net (80.231.130.6) 211.728 ms 209.843 ms 208.842 ms 10 if-4-2.tcore1.L78-London.as6453.net (80.231.130.33) 209.934 ms 207.888 ms 180.87.39.98 (180.87.39.98) 231.841 ms 11 if-6-2.tcore2.MLV-Mumbai.as6453.net (80.231.130.6) 216.820 ms * * 12 115.113.164.198.static-mumbai.vsnl.net.in (115.113.164.198) 211.738 ms 180.87.39.98 (180.87.39.98) 216.710 ms 231.669 ms 13 * 202.149.208.108 (202.149.208.108) 209.802 ms 209.841 ms 14 smtp.ttml.co.in (49.248.251.166) 240.824 ms 115.113.164.198.static-mumbai.vsnl.net.in (115.113.164.198) 213.843 ms *

(d)

Name Server:NS1.BITS-PILANI.AC.IN Name Server:NS2.BITS-PILANI.AC.IN

(e) Administrative Contact: Finance Team, APNIC

[email protected] APNIC Pty Ltd 6 Cordelia St, PO Box 3646 Brisbane, QLD 4101 AU +617-3858-3100 fax: +617-3858-3199 (f) For this, we use ‘netstat’ with various extensions. Example:- If we use ‘netstat –sp tcp’, we get response as,

If we use ‘netstat –sp udp’, we get response as,

(g)

All the TCP connections opened to access the website www.google.com

When we use ‘tracert’, we can see that it has only 2 TCP connections

‘Pathping’ command confirms the above point.

ANSWER 6

Part A.

Write appropriate Wireshark capture filters you need to capture the traffic described below.

I. Capture HTTP traffic. Does your filter work in the presence of proxy server too? Why (not)?

If we go for ‘display filter’, then we can just type ‘http’ in the ‘filter expression’ box.

Example:-

However, if we want to go for ‘capture filter’, we can do that only if we know the port number. Since in our

case we know that port number = 8080, so we can capture it. So the capture filter would be “tcp.port ==

8080”

Example:-

Yes, it is working for a proxy server as well. It automatically detects the proxy server through the application

layer.

II. Capture DNS traffic going to the name server 10.1.1.61.

The capture filter for such a case is “udp.port == 53 and ip.dst == 10.1.1.61”

III. Capture all the packets containing TCP connection setup and release segments.

To capture TCP packets, we use “tcp.stream” in the capture filter.

IV. Capture all the UDP packets going from 10.2.1.230 to 10.1.1.26

The capture filter will be “udp.port == 53 and ip.src == 10.2.1.230 and ip.dst == 10.1.1.26”

Part B. Use Wireshark to capture all the traffic coming to the NIC. Write a proper display filter for the following

scenarios.

I. All the RTSP packets.

To display RTSP packets, we have to use “rtsp” in the display filter.

For the capture filter, we cannot directly filter RTSP protocols while capturing. However, if you know the

TCP port used we can filter on that one. Here, the capture filter will be “tcp.port == 8080”

II. All the DHCPv6 packets from the localhost.

We can use “bootp” in the display filter.

If we use “dhcpv6” in the display filter,

III. All the packets containing HTTP requests to host www.bits-pilani.ac.in.

For this, we must know the destination ip address. So if do a dnsquery of the url www.bits-pilani.ac.in,

we can find where the name server is located. Then we can give the display or capture filter as

“http.request and ip.dst == 202.78.175.200”.

Or we can also use the string function of Wireshark expression field.

If we use the expression “http.request.uri contains www.bits-pilani.ac.in”, we can get all http requests

to that particular URL.

Example:-

IV. TCP stream between 10.2.1.230 and 10.1.1.26

We use the expression in the display or capture filter “tcp.stream and ip.src == 10.2.1.230 and ip.dst ==

10.1.1.26”

As an example, we have used source ip as 10.20.1.183.

ANSWER 7

(a) .flickr.com .yahoo.com .scorecardresearch.com s.yimg.com .google.com .youtube.com .google.co.in login.yahoo.com us.yahoo.com

(b) .flickr.com .yahoo.com .scorecardresearch.com s.yimg.com .google.com .youtube.com .google.co.in login.yahoo.com .google.co.in

3rd party cookies are:- r02.ycpi.in.yahoo.net (YahooTrafficServer) r07.ycpi.in.yahoo.net (YahooTrafficServer) ad.yieldmanager.com

(c)

(d)

The logout status of a google account user is indicated in the following way in the cookies: Set-Cookie: SID=EXPIRED; Set-Cookie: HSID=EXPIRED

Set-Cookie: SSID=EXPIRED; Set-Cookie: APISID=EXPIRED Set-Cookie: SAPISID=EXPIRED

Set-Cookie: LSID=EXPIRED

(e)

The main contents of the site comes from the site itself, but the ads come from another server or website. The browser assembles the different information fed from different sources so that all items appear on the same page.

For the browser to assemble the ads correctly, the website directs the browser to collect information from a different site's ad server. The third party website creates a cookie in the browser's folder as a result.

(f) 200 OK www.flickr.com 200 OK us.adserver.yahoo.com 200 OK us.bc.yahoo.com 200 OK geo.yahoo.com 302 Moved Temporarily b.scorecardresearch.com 200 OK login.yahoo.com 200 OK s.yimg.com 302 Found www.flickr.com 302 Moved Temporarily sb.scorecardresearch.com 302 Found open.login.yahoo.com 302 Moved Temporarily www.google.com 302 Moved Temporarily accounts.google.com 200 OK accounts.google.com 200 OK accounts.youtube.com 200 OK accounts.google.co.in 200 OK adjax.flickr.yahoo.com 302 Found cookex.amp.yahoo.com 302 Found ad.yieldmanager.com 200 OK apis.google.com 404 Not Found r07.ycpi.in.yahoo.net 204 No Content us.yahoo.com

ANSWER 8

(a)

We can do so by identifying the number of stack sequences of the identification numbers. If there is a large difference between two identification numbers, then they must have been sent by different hosts. The number of unique hosts will be equal to the number of sequence patterns. (b) If the identification numbers are not sequentially assigned but randomly assigned, then technique won't work because we cannot identify the sequence and hence the number computer behind the NAT which was sending them.

ANSWER 9

The following pages contain solution to answer 9.

NAT Traversal Techniques And

Peer-To-Peer Applications

Koustubh Laha BITS Pilani K.K. Birla Goa Campus

[email protected]

Arpit Gupta BITS Pilani K.K. Birla Goa Campus

[email protected]

Abstract— This paper reviews commonly existing and

Peer-to-Peer widely using NAT transversal techniques.

There is no heal-all technique to make NAT devices fully

inter-operable with P2P applications. On the other hand,

P2P applications could have to make use general purpose

method combined with special efforts to cope with

different NAT environment.

INTRODUCTION

Network Address Translation (NAT) is very useful in Small

Office and Home Office (SOHO) community to build a small

private network by sharing global routable IP addresses. The

main reason of the trouble is NAT mangling IP addresses and

port numbers thus breaking common end-to-end connections.

NAT Traversal Techniques is to let enable end-to-end protocol

and application packets through NAT gateway directly or

indirectly. Before delving deeper into the problem, we must

know the definitions of the terms we are going to deal with.

A. Network Address Translation (NAT)

Network Address Translation is a technique by which endpoint

IP address or IP address with TU port are translated from

private address realm to public address realm and back.

Network Address Translators both in software or hardware,

offer transparent routing to hosts by mapping private and

public address realms based on a conceptual communication

session. The main reason of NAT’s birth is the short-term

solution of IPv4 address depletion.

Figure 1: NAT Scenario.

A communication session between two hosts is identified as

the 4-tuple (local IP, local Port, remote IP, remote Port). The

most common NAT is traditional or outbound NAT which is

an asymmetric mapping between private address realm and

public address realm. Outbound NAT by default only permits

outbound sessions and blocks all incoming packets unless the

session is identified as an existing session initiated from

trusted private network host. Pure translations of addresses are

basic NAT. Both address and ports translations are Network

Address/Port Translation (NAPT). Obviously outbound NAT

conflicts with Peer-to- Peer communication. Bi-directional

NAT or Inbound NAT is to allow sessions initiated from either private or public hosts. A DNS-ALG must be deployed to

facilitate NAT for address and domain names mapping. A

NAT is session based on endpoint identities translation. NAT

device keeps an endpoint session address binding. Once the

first session address binding is created, the subsequent

sessions are associated with the same address binding. A new

address binding is created by starting a brand new session

between local and remote hosts. More complex, private hosts

might reside in multi-level NATs or a overlapped NATs when

two NAT environments merges with private address realm

overlapped.

B. Peer-to-Peer Network

Peer-to-Peer network is different with Client-Server network.

In Peer-to-Peer network peers have equal positions without

classification of client and server and peers are directly

connected by other peers. They act both as client and server

simultaneously.

PROBLEM STATEMENT

In NATed environment, general firewall/NAT role does not

allow incoming connection to private addressed hosts unless

private hosts initiate the connection at first or NAT is

specifically configured. The built-in privacy and security

benefits of NAT are private addressed hosts hiding. On the

other hand, this is a trouble because it is hard to locate and

communicate with the private hosts behind a NAT gateway.

How two private addressed hosts behind NATs could get to

know each other in the very beginning of the Peer-to-Peer

communication?

SOLUTION

The above problem demands NAT device makers, protocol

designers and Peer-to-Peer application vendors to provide

smooth and secure two way direct communication including

unsolicited incoming connection attempts for customers’ hosts

residing in NATed environments. Diverse NAT Traversal

Techniques offer a variety of NAT devices with transparent

traversal abilities to keep the end-to-end connection virtually.

Some of them are NAT gateway optimized and plugged

techniques such as Universal Plug and Play (UPnP),

Application Lever Gateway (ALG). Some of them are fall-

back (make use of Client-Server model) approaches, by which they use a relay server or introducer server on either side of

NAT gateway or both sides, such as STUN and TCP/UDP

hole punching. No single NAT traversal technique is suitable

for all NAT necessary environments since NAT is not

standard, that is, no single Peer-to-Peer application could work

smoothly in all NATed hosts. Some of the techniques have

been described below.

C. Universal Plug and Play (UPnP)

UPnP is architecture and open standard for flexible

connectivity of intelligent both wired and wireless devices. The automatic service discovery, addressing, zero

configuration are suitable for SOHO. UPnP’s specification is

based TCP/IP. Windows Internet Connection Sharing (ICS) is

UPnP enabled. When a new host needs a connection, UPnP

device can automatically configure network addressing,

announce its presence on a network subnet, and permit the

exchange of device and service descriptions. A Windows XP-

based computer application could detect that if it is behind an

UPnP-enabled NAT device. Then the application can learn the

shared, globally-routable IP address, and configure UDP and

TCP port mappings to forward packets from the external ports of the NAT to the internal ports.

D. Simple Traversal UDP Through Network Address

Translators (STUN)

STUN is lightweight protocol to allow the applications in

private address realm to discover the presence of NAT devices

and type of NAT between them and public address realm. The

steps followed by it are:-

1. STUN client asks the STUN server for a temporary

user name and password for subsequence Binding Requests and Binding Responses’ packets integrity

check and authentication.

2. The STUN client sends a Binding Request to STUN

Server which typically resides in public address

realm.

3. The request UDP packet may traverse several NAT

devices to arrive STUN server.

4. The Server could learn the last NAT modified source

address and port.

5. The STUN server then copies the source address and

port into a Binding Response and sends it back to the STUN client.

By comparing itself local address and port in response packet,

STUN client could learn if it is behind a NAT device. By

sending two Binding Requests from the same source address

and port to two different IP addresses, STUN client could

further learn if it is behind a symmetric NAT device.

Figure 2: STUN Scenario

The advantage of STUN is it does not require any changes on

NAT devices. On the other side, STUN is just a short term

solution. It does not work with symmetric NAT which is

commonly used by large corporate users. STUN requires

client application upgraded to support STUN and an additional

STUN server residing in public Internet.

E. Application Level Gateway (ALG)

In the context of computer networking, an application-level

gateway (also known as ALG or application layer gateway)

consists of a security component that augments a firewall or

NAT employed in a computer network.

It allows customized NAT traversal filters to be plugged into

the gateway to support address and port translation for certain

application layer "control/data" protocols such as FTP,

BitTorrent, SIP, RTSP, file transfer in IM applications etc.

In order for these protocols to work through NAT or a firewall, either the application has to know about an

address/port number combination that allows incoming

packets, or the NAT has to monitor the control traffic and

open up port mappings (firewall pinhole) dynamically as

required. Legitimate application data can thus be passed

through the security checks of the firewall or NAT that would

have otherwise restricted the traffic for not meeting its limited

filter criteria.

F. UDP and TCP hole punching

UDP and TCP hold punching is general purpose, robust technique to establish peer-to-peer communication in Peer-to-

Peer network. The main idea of hole-punching is to have a

relaying server which could be reached by clients both or

either behind NAT. Two clients send registration message

containing private IP address, TU port and public IP address,

TU port to relay server. Relay server then introduces two

clients to know each other private and public IP address and

TU port. UDP hold punching works well for clients behind

same NAT, clients behind different NATs and multiple level

NATs. TCP hold-punching requires a single local TCP port to

listen to an incoming TCP connection and to initiate multiple

outgoing TCP connections concurrently.

Figure 3: Hole-Punching with two clients behind different

NAT Scenario

This requires operating system and API support. Hole-

punching does not work with symmetric NAT.

DISADVANTAGES AND SHORTCOMINGS

So far we have seen how we can solve the problem which a

regular NATed network creates. But the above methods also

come with a lot of disadvantages or security constrictions. We

will see them point-by-point.

G. Avoidance of IP address

NAT is not aware of embedded IP address and ports so that

private un-routable address leaks publicly because NAT

would not do proper address mapping. Protocol designers and

application makers should avoid using IP address and TU

ports in payload directly.

H. ALG Complexity

With use of ALG, NAT can allow inbound connections. But

this technique would not work without additional software

upgrade on NAT device. This increases device cost and

decreases the popularity of ALG thus dis-encourage designers

to use ALG to make NAT friendly to Peer-to-Peer

applications.

I. Reuse session address binding

Symmetric NAT does not offer the reuse of session address

binding resulting in TU hole punched not possibly being further used for Peer-to-Peer subsequent communication. It is

suggested to keep a single connection as possible as it could.

NAPT NAT TU timers should be set properly to allow

maximum use of session address binding and to recycle TU

port resource.

J. Peer-to-Peer application automatic and manual

configuration

Peer-to-Peer application is suggested to use hybrid approach:

combine pure Peer-to-Peer with Client-Server network.

Automatically NAT detection and awareness for peer client is

important to diagnose the type of behavior of NAT device,

even multi-level NATs. This technique requires at least one

dedicated response server to give exploratory response

messages to peer clients.

K. Security Concerns

There is always an engineering trade-off between open and security. Client-Server model is less open than Peer-to-Peer

model and it is more secure with NAT and firewall. Currently

NAT traversal techniques are to modify NAT device and

firewall to let Peer-to-Peer application packets going through.

Techniques like hole-punching opens a two way TU port hole

in NAT/Firewall. Naive NAT and Firewall cannot simply

recognize whether reused session binding is secure or not.

NAT breaks the open end-to-end connection. This introduces

more complexity of security implementation.

CONCLUSION

In order to make NAT devices friendly to Peer-to-Peer

applications, many NAT traversal techniques are invented.

Some technique has limitation resulting in less popularly

acceptance and slow deployment. Some technique like hole-

punching is widely deployed and general purpose method. For

SOHO community, due to the limit knowledge about network

and device, management and configuration NAT is pessimistic

for end users. Most Peer to Peer service chooses hole-

punching as a general purpose method to transverse NATs.

Relaying server is a fall-back strategy of using Client-Server

model to solve peer-to-peer network problem. Using hybrid

approach is a make shift and practical way. In the short term, NAT will widely exist and there is no single

technique which could solve diverse NAT traversal problems.

In the long term, IPv6 would offer enough address space to

accommodate any IP based terminals. It is said IPv6 could

offer each grain of sand a unique address on the planet. At that

time, NAT might not be necessary. However those techniques

like hole-punching and UPnP is still very useful on IPv6 era.

REFERENCES

Zhou Hu, NAT Traversal Techniques and Peer-to-Peer Applications, Telecommunications Software and Multimedia Laboratory; Helsinki University of Technology; hzhou@ cc.hut.fi

A New Method for Symmetric NAT Traversal in UDP and TCP

Koustubh Laha

BITS Pilani K.K. Birla Goa Campus

[email protected]

Arpit Gupta

BITS Pilani K.K. Birla Goa Campus

[email protected]

Abstract — This paper proposes a new method for Network

Address Translator (NAT) Traversal in UDP. Existing NAT

traversal methods cannot traverse symmetric NAT boxes. This

method uses a new port prediction method which helps solve the above problem. It is based on new UDP hole punching technique.

II. INTRODUCTION TO PROBLEM STATEMENT

A network address translator (NAT) is a well-known, versatile tool that enables the reuse of IP addresses in the

Internet. However, a fatal problem can occur if an applications

protocol includes an IP address as part of the payload of IP

packets. There have been many proposals to solve this

problem. Existing NAT traversal methods like Universal Plug

and Play (UPnP), Simple traversal of UDP over NATs (STUN)

and Teredo, cannot traverse symmetric NAT boxes.

This paper proposes a new method for NAT traversal, which is

applicable to symmetric NATs as well as other types of NATs.

This new method is based on port prediction. It manipulates

port numbers in order to traverse symmetric NATs

successfully. Several experiments have been conducted to

evaluate the performance of this new method. The results show

that this method can be practically implemented for successful

NAT traversal.

In this review, we describe the various types of NATs. Then

we survey the existing methods of NAT traversal. Later the new method is proposed. We also see the results of the

experiments conducted finally concluding the review.

III. TAXONOMY OF NAT

Full Cone, Restricted Cone, Port Restricted Cone and

Symmetric are the different types of NATs. For better

understanding, we use the following terms:-

1. Addr – node address with prefix i – internal; e –

external; h - host;

2. Port – node port number with prefix i – internal; e –

external; h - host;

A. Full-cone NAT

Once an internal address (iAddr: iPort) is mapped to an

external address (eAddr: ePort), any packets from (iAddr:

iPort) will be sent through (eAddr: ePort). Any external host

can send packets to (iAddr: iPort) by sending packets to

(eAddr: ePort).

B. Address restricted cone NAT

Once an internal address (iAddr: iPort) is mapped to an

external address (eAddr: ePort), any packets from iAddr: iPort

will be sent through (eAddr: ePort).

An external host (hAddr: any) can send packets to (iAddr:

iPort) by sending packets to (eAddr: ePort) only if (iAddr:

iPort) has previously sent a packet to (hAddr: any). "Any"

means the port number doesn't matter.

C. Port-restricted cone NAT

Similar to an address restricted cone NAT, but the restriction

includes port numbers.

Once an internal address (iAddr: iPort) is mapped to an

external address (eAddr: ePort), any packets from iAddr: iPort)

will be sent through (eAddr: ePort). An external host (hAddr:

hPort) can send packets to iAddr: iPort) by sending packets to

(eAddr: ePort) only if (iAddr: iPort) has previously sent a

packet to (hAddr: hPort).

D. Symmetric NAT

Each request from the same internal IP address and port to a

specific destination IP address and port is mapped to a unique

external source IP address and port, if the same internal host

sends a packet even with the same source address and port but

to a different destination, a different mapping is used.

Only an external host that receives a packet from an internal

host can send a packet back.

IV. EXISTING SOLUTIONS TO THE PROBLEM

There have been many proposals on methods to traverse NATs.

This section describes some well-known techniques such as

UPnP, STUN, and Teredo. However, they cannot be applied to

Symmetric NAT.

A. UPnP

In a UPnP architecture ,when a new host needs a connection,

the UPnP device can automatically configure a network

address, announce its presence on the network subnet, and

exchange a description of device and services. NAT traversal

in UPnP is known as the Internet Gateway Device (IGD)

Protocol. However, one of the disadvantages of UPnP is that it

requires that all the devices in the network should support

UPnP.

B. STUN

STUN is a protocol used for communication between a client

and a server. If a peer-to-peer software package includes a

STUN client, it sends a request to a STUN server. The server

then reports back to the STUN client about the global IP

address of the NAT router. One of the drawbacks of STUN is

that it does not work with symmetric NATs. STUN cannot

handle symmetric NATs because the global IP address and port

number translated from the private address and port number of

the client are not fixed.

C. Teredo

Based on IPv6 tunneling technology proposed by Microsoft, a

Teredo client obtains a Teredo IPv6 address from the Teredo

server. It utilizes an IPv6 address with IPv6 tunneling in UDP/IPv4.It communicates with other Teredo clients and other

IPv6 nodes through a Teredo relay. A Teredo server should

have both an IPv4 global address and an IPv6 global address.

A Teredo relay should have an IPv4 global address and an IPv6

global address. It provides routing between the Teredo clients

and nodes on the IPv6 Internet.

V. INTRODUCTION OF A NEW METHOD

In this section we propose a new method for UDP multi-hole

punching. This method establishes a UDP connection between

two end points through NATs. The new method is based on

port prediction and limited TTL values. It controls the port numbers to allow successful traversing of symmetric NATs. It

also works well for the other types of NATs. In addition, the

new method can be extended to NAT traversal in TCP.

The following steps elaborate the process.

F1. The echo client communicates with S1. Then, S1

analyzes the port number mapped by NATa.

F2. S1 conveys the port number to the echo client.

F3. The echo client sends a packet to S2. It includes

information obtained on the port number of NATa

when the echo client communicated with S1. Then, S2

analyzes the port number of NATa and records it.

Furthermore, S2 also records the information obtained

on the port number of NATa when the echo client

communicated with S1 at step F1.

F4. The echo server communicates with S1. Then, S1

analyzes the port number mapped by NATb.

F5. S1 conveys the port number to the echo server.

F6. The echo server sends a packet to S2. The packet

includes the port number information of NATb obtained from the communication of the echo server

with S1 at step F4. Then, S2 analyzes the port number

of NATb and records it. Furthermore, S2 records the

port number information of NATb obtained when the

echo server communicated with S1 at step F4.

F7. Based on the two types of information communicated

in phases I and II, namely the communications of

NATa with S1 and S2, we can predict a suitable port

number for hole-punching. We can also determine the

punching mode. S2 sends the information containing

the predicted port number and the punching mode to

the echo server.

F8. Based on this information, the echo server sends a

large number of packets. These packets have a fixed

destination port and a low TTL value. The echo server binds the port. The packets are then sent to the echo

client.

F9. Using the two kinds of information obtained in phases

I and II, namely, the communications of NATb with

S1 and S2, we can predict a suitable port number for

the hole-punching. S2 sends the information that

contains the predicted port number and the punching

mode to the echo client in a manner similar to that of

step F7.

F10. On the basis of the information obtained in step F9,

the echo client sends many packets to the echo server. These packets have a fixed destination port. The echo

client binds the port. After sending all the packets, the

echo client switches to the receiving mode.

F11. The echo server replies to the echo client. It

establishes a P2P connection between the echo client

and the echo server at this stage.

VI. ADVANTAGES

A. Normal UDP communications

The new method puts small TTL value, 2 or 3, in a packet from

the Echo Server. These packets appear normal UDP

communications if we neglect the extra packets. Thus, UDP packets have less possibility of being discarded because of the

use of security criteria for screening packets at NATs.

B. Precise port number prediction

Most NATs translate port numbers according to one of the

following algorithms: (i) increment, (ii) decrement, (iii) leap,

i.e., skipping alternative port numbers, or random. The

proposed method uses two servers so that we can observe any

type of port translation.

C. Control of port numbers

The new method uses fixed port numbers rather than random

numbers. When the source port numbers are {x, x + 1, x +

2 . . .} and the translated port numbers are {n, n + 1, n + 2 . . .},

it can detect the translation algorithm at a NAT based on the

sequences of the source ports and the translated ports.

D. Use of many port numbers

The new method uses many port numbers. The current

implementation uses 1,000 port numbers. The large number of

ports increases the success rate of hole-punching. When

NAT a translates port numbers by some unknown algorithm

and one of the 1,000 ports matches with the mapping of NATb,

the communication is successfully established.

E. Stateful Packet Inspection (SPI) in TCP

Currently, many NAT products are equipped with Stateful

Packet Inspection (SPI). It is a type of function for filtering of

TCP packets. When SPI is applied, a valid sequence of packets

should follow the 3-way handshake of TCP. The 3- way

handshake is as follows:

1. [SYN] - outgoing

2. [SYN, ACK] - incoming

3. [ACK] - outgoing

The proposed method can be extended to cover TCP NAT

traversal.

VII. EXPERIMENTAL PROCEDURE

The following methods were used as experimental procedures.

A. Classification of Types of NAT using WinSTUN

WinSTUN was used to classify NATs. The following

illustration shows the network configuration for the

experiment.

B. Packet Capturing

In order to study the port translation algorithm, we used packet

capture software. This software monitors the port number information in the packets. The test was conducted for a fixed

source port number of 5323. The packets are sent to the

appropriate destination port, whose number is changed using

the incremental algorithm. The following illustration shows the

network configuration for the experiment.

The packets were captured at a switch, where a mirror function

had been enabled.

C. Use of Skype Software for NAT Traversal

Skype uses three types of communication methods — P2P,

UDP-RELAY, and TCP-RELAY. The communication

methods of Skype were observed using the analysis window of

Skype.

VIII. NEW METHOD IN TCP

The performance of the new method for traversing NATs in

TCP was tested. The extended method is based on UDP hole-

punching. It uses UDP communication to exchange

information over a TCP connection. It then simulates the TCP

3-way handshake sequence and generates a sequence of TCP

segments with proper sequence numbers. The results showed

that the new method can successfully traverse NATs in TCP

for five out of six products. It has one failure because the

specific product has a filtering function on port numbers as well

as SPI. It allows a local port is designated to unique destination

at {IP address, port} only. It is more restrictive than SPI.

CONCLUSION

The new method needs two servers increasing the cost of

infrastructure. But the high success rate can justify the

overhead cost in the proposed method. This new method can

also be used for TCP hole punching, which is more difficult

than UDP hole punching if existing methodologies are

followed.

REFERENCES

[1] Yuan Wei, Daisuke Yamada, Suguru Yoshida and Shigeki Goto, ―A New Method for Symmetric NAT Traversal in UDP and TCP‖ ; Waseda University, 3-4-1 Okubu, Shinjuku-ku, Tokyo, Japan.