Transcript IP: Internet Protocol

IP: Internet Protocol
• IP is the workhorse protocol of the TCP/IP
protocol suite
• IP provides an unreliable, connectionless,
datagram delivery service
• The internet protocol implements two basic
functions: addressing and fragmentation.
• RFC791 is the official specification of IP
7/17/2015
Internet Protocol
1
The Workhorse
User
Process
User
Process
User
Process
TCP
7/17/2015
User
Process
UDP
transport
ICMP
IP
IGMP
ARP
Hardware
Interface
RARP
Internet Protocol
application
network
link
2
IP Header
8
16
Version Hdr Len Type of Service
Identification
Time to Live
31
Total Length (in bytes)
Flags
Protocol
Fragment offset
Checksum
20 bytes
Source IP Address
Destination IP Address
options (if any)
data
7/17/2015
Internet Protocol
3
Network Byte Ordering
• Multi-byte numbers can be stored in one of two
ways:
– 6000010 = 00000000 00000000 11101010 01100000
Address
Addr0
Addr1
Addr2
Addr3
Big Endian
00000000
00000000
11101010
01100000
Little Endian
01100000
11101010
00000000
00000000
• Network byte order is big endian
7/17/2015
Internet Protocol
4
IP Header Fields
Field
Version
Header Length
Total Length
Time to Live
7/17/2015
Description
The Version field indicates the format of the internet
header. The current protocol version is 4 (sometimes
called IPv4)
The length of the header in 32-bit words. Note that
the minimum value for a correct header is 5.
The total length of the IP datagram in bytes (data and
header)
Sets an upper limit on the number of routers through
which a datagram can pass. It is initialized by the
sender (often 32 or 64) and decremented by one each
time the packet passes through a router. When it
reaches 0, the packet is discarded
Internet Protocol
5
Type of Service
• The IP protocol provides a (rather limited) facility
for upper layer protocols to convey hints to the
Internet Layer about how the tradeoffs should be
made for the particular packet
3-bit
precedence
7/17/2015
4-bit
TOS
Internet Protocol
MBZ
6
TOS Field Values
• There are 4 defined values for the TOS field
Value
1000
0100
0010
0001
0000
Meaning
Minimize delay
Maximize throughput
Maximize reliability
Minimize monetary cost
Normal service (default)
• Note these values are defined as integers, not as
bits
7/17/2015
Internet Protocol
7
Recommended TOS Values
7/17/2015
Application
Minimize Maximize
Delay
Throughput
Maximize
Reliability
Hex Value
0
Minimize
Monetary
Cost
0
Telnet/Rlogin
FTP
Control
Bulk
TFTP
SMTP
Command
Data
DNS
UDP query
TCP query
Transfer
ICMP
Error
Query
SMNP
BOOTP
NNTP
1
0
1
0
1
0
1
0
0
0
0
0
0
0
0x10
0x08
0x10
1
0
0
1
0
0
0
0
0x10
0x08
1
0
0
0
0
1
0
0
0
0
0
0
0x10
0x00
0x08
0
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
1
0x00
0x00
0x02
0x00
0x01
Internet Protocol
0x10
8
Fragmentation
• The physical layer often imposes an upper limit on
the size of the frame that can be transmitted
• IP compares the MTU with the datagram size and
performs fragmentation, if necessary
• Fragmentation can take place at the original host
or at an intermediate router
• IP datagrams are not reassembled until they reach
their final destination
7/17/2015
Internet Protocol
9
Fragmentation and the Header
• The following fields are used in fragmentation
– identification
• contains a unique value for each IP datagram that the sender
transmits
– flags
MBZ
Don’t
fragment
More
fragments
– fragment offset
• the offset of the fragment from the beginning of the original
datagram
7/17/2015
Internet Protocol
10
Fragmentation
• If fragmentation must occur…
– if the “don’t fragment” bit is turned on the packet is
discarded
– the packet is split into fragments
• the header is basically copied except for…
– total length is changed to the size of the fragment
– the fragmentation offset is set to the the offset of the fragment
from the beginning of the original datagram
– the “more fragments” bit is turned on in every fragment except
for the last one
7/17/2015
Internet Protocol
11
Reassembly
• The identification field is used to ensure that
fragments of different datagrams are not mixed.
• The fragment offset field tells the receiver the
position of a fragment in the original datagram
• The fragment offset and length determine the
portion of the original datagram covered by this
fragment
• The more-fragments flag indicates (by being reset)
the last fragment
7/17/2015
Internet Protocol
12
Protocol Field
• This field indicates the next level protocol used in
the data portion of the internet datagram
• The values for various protocols are specified in
RFC1060 (Assigned Numbers)
Number
0
1
2
6
17
7/17/2015
Protocol
Reserved
ICMP
IGMP
TCP
UDP
Internet Protocol
13
Header Checksum
• The header checksum is calculated over the IP
header only
• The checksum is calculated as follows:
– set the checksum field to 0
– calculate the 16-bit one’s complement sum of the
header
– the 16-bit one’s complement of this sum is stored in the
checksum field
7/17/2015
Internet Protocol
14
Header Checksum
• When an IP datagram is received, the 16-bit one’s
complement sum of the header is calculated
• Since the receiver’s calculated checksum contains
the checksum stored by the sender, the calculated
result should be all ones
• If the checksum is wrong, the packet is quietly
discarded. No error messages are generated
• ICMP, IGMP, UDP, and TCP all use the same
checksum
7/17/2015
Internet Protocol
15
Addressing
• A distinction is made between names, addresses,
and routes
– A name indicates what we seek
– An address indicates where it is
– A route indicates how to get there
• The internet protocol deals primarily with
addresses. It is the task of higher level protocols
to make the mapping from names to addresses.
7/17/2015
Internet Protocol
16
IP Addresses
• Every interface on the internet must have a unique
Internet Address (also called an IP address)
• IP addresses are 32-bits numbers
• The addresses are not flat, they are divided into
two components: the host address and the
network address
• The number of bits assigned to the host portion
and network portion of the address varies
depending on the class of the address
7/17/2015
Internet Protocol
17
IP Address Classes
7 bits
Class A
Class B
Class C
0
1
1
24 bits
netid
hostid
0
1
0
14 bits
16 bits
netid
hostid
21 bits
8 bits
netid
hostid
28 bits
Class D
1
1
1
0
multicast group ID
27 bits
Class E
1
7/17/2015
1
1
1
0
(reserved for future use)
Internet Protocol
18
Dotted Decimal Notation
• IP addresses are normally written as four decimal
numbers, one for each byte of the address.
– 129.21.38.169
• The easiest way to differentiate between the
classes is to look at the first number
Class
A
B
C
D
E
7/17/2015
Range
0.0.0.0 to 127.255.255.255
128.0.0.0 to 191.255.255.255
192.0.0.0 to 223.255.255.255
224.0.0.0 to 239.255.255.255
240.0.0.0 to 247.255.255.255
Internet Protocol
19
Assigning IP Addresses
• Since every interface must have a unique IP
address, there must be a central authority for
assigning numbers
• That authority is the Internet Network Information
Center, called the InterNIC.
• The InterNIC assigns only network ids, the
assignment of host ids is up to the system
administrator
7/17/2015
Internet Protocol
20
Subnet Addressing
• The original view of the Internet universe was a
two-level hierarchy:
– the top level the Internet as a whole
– the level below it individual networks, each
with its own network number.
• In this two-level model, each host sees its network
as a single entity
7/17/2015
Internet Protocol
21
Subnet Addressing
• While the two-level view has proved simple and
powerful, a number of organizations have found it
inadequate, and have added a third level to the
interpretation of Internet addresses.
• In this view, a given Internet network is divided
into a collection of subnets.
• The three-level model is useful in networks
belonging to moderately large organizations
7/17/2015
Internet Protocol
22
Subnet Addressing
• Locally IP addresses consist of three parts:
– network ID
– subnet ID
– host ID
• Outside of the subnetted network the addresses are
handled normally
• Inside the subnet, the network portion of the
address is extended for local routing purpose
7/17/2015
Internet Protocol
23
Subnet Masks
• Once the decision to subnet has been made, the
local administrator must decide how many bits to
allocate to the subnet ID
• A common division is to use the 8-bit boundary in
the 16 bits of a host ID in a class B address
• A subnet mask is used to divide the local address
into network and host portions
• Subnetting effectively hides the details of the
internal network to external routers
7/17/2015
Internet Protocol
24
Special IP Addresses
IP Address
Net ID Subnet ID Host ID
0
0
0
hostid
127
anything
255
255
netid
255
netid
Subnetid 255
netid
255
255
7/17/2015
Can Appear as
Source? Destination?
OK
Never
OK
Never
OK
OK
Never
OK
Never
OK
Never
OK
Never
OK
Description
This host on this net
Specified host on this net
Loopback address
Limited broadcast (never forwarded)
Net-directed broadcast to netid
Subnet-direct broadcast to netid, subnetid
All-subnets-directed broadcast to netid
Internet Protocol
25
IP Options Field
• The options field is a variable-length list of
optional information for the datagram
• The options currently defined are
–
–
–
–
security and handling restrictions (RFC1108)
record route
timestamp
loose & strict source routing
• The options field always ends on a 32-bit
boundary
7/17/2015
Internet Protocol
26
IP Routing
• Routing is one of the most important functions of
IP
• Datagrams to be routed can either be generated on
the local host or on some other host
• If a machine is not configured as a router,
datagrams received through network interfaces
that are not addressed to the machine are dropped
7/17/2015
Internet Protocol
27
Host Routing
• Conceptually IP routing is easy, especially for a
host
– Remember the structure of an internet address
• If the destination is directly connected to the host,
or on a shared network, then the datagram is sent
directly
• Otherwise the host sends the datagram to a default
router, and lets the router do all of the work
7/17/2015
Internet Protocol
28
IP routing Algorithm
• The basic internet routing algorithm is used by
both hosts and routers
• The primary difference is that hosts never forward
datagrams (except to a default router), whereas
routers forward datagrams
• The algorithm uses a routing table to make routing
decisions
7/17/2015
Internet Protocol
29
A Typical Routing Table
• Each entry in the routing table contains the
following information
– Destination IP address.
• this can be either a host address or a network address
– IP address of the next-hop router, or the IP address of a
directly connected network
– Flags that tell more about the entry
– Which interface the datagram should be passed to for
delivery
7/17/2015
Internet Protocol
30
IP routing
• IP routing performs the following actions
– search the routing table for an entry that matches the
complete destination address. If found, send the packet
as indicated
– search the routing table for a matching destination
network ID. If found, send the packet as indicated
– search the routing table for a default entry. If found
send the packet as indicated
• If none of the steps work, the datagram is
undeliverable
7/17/2015
Internet Protocol
31
IP Layer Routing
7/17/2015
Internet Protocol
32
IP Routing
• The routing done by IP, when it searches the
routing table and decides which interface to
send a packet out, is a routing mechanism
• A routing policy is a set of rules that determines
which routes go into the routing table.
• IP performs the routing mechanism while a
routing daemon normally provides the routing
policy.
7/17/2015
Internet Protocol
33
Initializing a Routing Table
• One common way is to execute the route
command explicitly from the initialization files
when the system is being bootstrapped.
• Some systems allow a default router to be
specified in a file such, and this default is added to
the routing table on every reboot.
• Other ways to initialize a routing table are to run a
routing daemon or to use the newer router
discovery protocol.
7/17/2015
Internet Protocol
34
Routing Errors
• What happens if there is no default route, and a
match is not found for a given destination?
• If the datagram was generated locally, an error is
returned to the application that sent the datagram
(either “host unreachable” or “network
unreachable”)
• What do I do if I am a router?
– Sender should be notified of the error
7/17/2015
Internet Protocol
35
Internet Control Message Protocol
• ICMP communicates error messages and other
conditions that require attention
• ICMP is often considered part of the IP layer
• RFC792 is the official specification for ICMP
• ICMP messages are transmitted within IP
datagrams
7/17/2015
Internet Protocol
36
ICMP Packet Format
• The first 4 bytes of the same format for all
messages, the remainder differs from one message
to the next
8-bit type
8-bit code
16-bit checksum
contents depend on type and code
7/17/2015
Internet Protocol
37
ICMP Message Types
Type
0
3
4
7/17/2015
Code
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
Description
Echo reply
Destination unreachable:
Network unreachable
Host unreachable
Protocol unreachable
Port unreachable
Fragmentation needed
Source route failed
Destination network unknown
Destination host unknown
Source host isolated
Destination net prohibited
Destination host prohibited
Network unreachable for TOS
Host unreachable for TOS
Communication prohibited
Host precedence violation
Precedence cutoff in effect
Source quench
Internet Protocol
Query

Error
















38
ICMP Message Types
Type
5
8
9
10
11
Code
0
1
2
3
0
0
0
0
1
12
13
14
15
16
17
18
7/17/2015
0
1
0
0
0
0
0
0
Description
Redirect
Redirect for network
Redirect for host
Redirect for TOS and Net
Redirect for TOS and Host
Echo request
Router advertisement
Router solicitation
Time exceeded
TTL equals 0 during transit
TTL equals 0 during reassembly
Parameter problem
IP header bad
Required option missing
Timestamp request
Timestamp reply
Information request
Information reply
Address mask request
Address mask reply
Internet Protocol
Query
Error

















39
ICMP Error Messages
• When an ICMP error message is sent, the message
always contains the IP header and the first 8 bytes
of the IP datagram that caused the problem
• ICMP has rules regarding error message
generation to prevent broadcast storms
7/17/2015
Internet Protocol
40
Error Message Generation Rules
• ICMP errors messages are not generated in
response to
–
–
–
–
–
7/17/2015
an ICMP error message
datagrams destined to an IP broadcast address
datagrams sent as a link-layer broadcast
a fragment other than the first
a datagram whose source address does not define a
single host
Internet Protocol
41
ICMP Timestamp Request & Reply
• This option allows a system to query another for
the current time.
• The recommended value to be returned is the
number of milliseconds since midnight,
Coordinated Universal Time (UTC).
• A drawback is that only the time since midnight is
returned. The caller must know the date form
some other means
7/17/2015
Internet Protocol
42
Timestamp Message Format
type (13 or 14)
code (0)
identifier (can be set to anything)
16-bit checksum
sequence (can be set to anything)
32-bit originate timestamp
32-bit receive timestamp
32-bit transmit timestamp
7/17/2015
Internet Protocol
43
Time Adjustments
• The time fields are defined as follows
– originate: time the request is sent
– receive: time the request is received by the receiver
– transmit: time the reply is sent
originate
received
request
reply
transmit
RTT
• Adjustment: (recv - orig) - (0.5 * RTT)
7/17/2015
Internet Protocol
44
ICMP Unreachable Error
• Unreachable errors are generate for a number of
reasons
– network unreachable
– host unreachable
type (3)
code (0-15)
16-bit checksum
unused (must be 0)
IP header (including options) + first 8 bytes of IP datagram data
7/17/2015
Internet Protocol
45
Handling of ICMP Messages
Type
0
3
4
7/17/2015
Code
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
0
Description
Echo reply
Destination unreachable:
Network unreachable
Host unreachable
Protocol unreachable
Port unreachable
Fragmentation needed
Source route failed
Destination network unknown
Destination host unknown
Source host isolated
Destination net prohibited
Destination host prohibited
Network unreachable for TOS
Host unreachable for TOS
Communication prohibited
Host precedence violation
Precedence cutoff in effect
Source quench
Internet Protocol
Handled by
User process
“No route to host”
“No route to host”
“Connection refused”
“Connection refused”
“Message too long”
“No route to host”
“Network is unreachable”
“No route to host”
“No route to host”
“Network is unreachable”
“No route to host”
“Network is unreachable”
“No route to host”
(ignored)
(ignored)
(ignored)
Kernel for TCP; ignored by UDP
46
Handling of ICMP Messages
Type
5
8
9
10
11
Code
0
1
2
3
0
0
0
0
1
12
13
14
15
16
17
18
7/17/2015
0
1
0
0
0
0
0
0
Description
Redirect
Redirect for network
Redirect for host
Redirect for TOS and Net
Redirect for TOS and Host
Echo request
Router advertisement
Router solicitation
Time exceeded
TTL equals 0 during transit
TTL equals 0 during reassembly
Parameter problem
IP header bad
Required option missing
Timestamp request
Timestamp reply
Information request
Information reply
Address mask request
Address mask reply
Internet Protocol
Handled by
Kernel updates routing table
Kernel updates routing table
Kernel updates routing table
Kernel updates routing table
Kernel generates reply
User process
User process
User process
User process
“Protocol not available”
“Protocol not available”
Kernel generates reply
User process
Kernel generates reply
User process
Kernel generates reply
User process
47
ICMP Redirect Errors
• The ICMP redirect error is sent by a router to a
sender of an IP datagram when the datagram
should have been sent to a different router.
7/17/2015
Internet Protocol
48
Sending a Redirect
• How can a router make this decision?
– Assume a host sends an IP datagram to R1. This routing
decision is often made because R1 is the default router
– R1 receives the datagram and determines that R2 is the
next-hop router
– When it sends the datagram to R2, R1 detects that it is
sending it out the same interface on which the
datagram arrived.
– R1 sends an ICMP redirect to the host, telling it to send
future datagrams to that destination to R2
7/17/2015
Internet Protocol
49
Using Redirects
• A common use for redirects is to let a host with
minimal routing knowledge build up a better
routing table over time.
• The host can start with a default route and anytime
this turns out to be wrong, it will be informed by
that router with a redirect, allowing the host to
update its routing tables accordingly.
7/17/2015
Internet Protocol
50
Redirect Rules
• There are rules regarding the generation of ICMP
redirects.
– Redirects are generated only by routers, and not by
hosts
– Redirects are intended to be used by hosts, not by
routers (it is assumed that routers participate in a
routing protocol with other routers, and the routing
protocol eliminates the needs for redirects)
7/17/2015
Internet Protocol
51
Handling Redirects
• A host that receives an ICMP redirect performs
some checks before modifying its routing table
– the new router must be on a directly connected network
– the redirect must be from the current router for that
destination
– the redirect cannot tell the host to use itself as the router
– the route that is being modified must be a direct route
• Routers should send only host redirects and not
network redirects
7/17/2015
Internet Protocol
52
ICMP Router Discovery
• A newer way to initialize a routing table is to use
the ICMP router advertisement and solicitation
• The general concept is that after bootstrapping, a
host broadcasts or multicasts a router solicitation
message. One or more routers respond with a
router advertisement message
• Routers periodically broadcast or multicast their
router advertisements
• RFC1256 specifies the format of these messages
7/17/2015
Internet Protocol
53
Message Formats
7/17/2015
Internet Protocol
54
Router Discovery Messages
• Multiple addresses can be advertised by a router in
a single message
– number of addresses gives the number of addresses in
the message
– address entry size is the number of 32-bit words for
each router address and is always 2
– lifetime is the number of seconds that the advertised
addresses can be considered valid
7/17/2015
Internet Protocol
55
Router Discovery Messages
• Pair(s) of IP addresses and a preference then
follow (the address must be router's IP address)
• The preference level indicates the preference of
this address as a default router
– Larger values imply more preferable addresses.
– The preference level 0x80000000 indicates that the
corresponding address, although advertised, should not
be used by the receiver as a default router address
– The default value is normally 0.
7/17/2015
Internet Protocol
56
Router Discovery Operation
• When a router starts up it transmits periodic
advertisements on all interfaces capable of
broadcasting or multicasting
• The default lifetime for a given advertisement is
30 minutes.
• The lifetime field is is also used when an interface
on a router is disabled. In this case the router
transmits an advertisement with lifetime set to 0.
7/17/2015
Internet Protocol
57
Router Discovery Operation
• A router also listens for solicitations from hosts. It
responds to these solicitations with a router
advertisement.
• If there are multiple routers on a subnet, it is up to
the system administrator to configure the
preference level for each router as appropriate. For
example a primary router would have a higher
preference than a backup.
7/17/2015
Internet Protocol
58
Host Discovery Operation
• Upon bootstrap a host normally transmits three
router solicitations, 3 seconds apart
• A host listens for advertisements from adjacent
routers. These advertisements can cause the host's
default router to change
• If an advertisement is not received for the current
default, that default can timeout
– A router will send advertisements every 10 minutes,
with a lifetime of 30 minutes
7/17/2015
Internet Protocol
59
CS Network
129.21.38.254
mordor-38
129.21.38.218
129.21.37.254
mordor-39
129.21.37.218
129.21.39.218
129.21.30.26
ICL1
ICL4
Grad Lab
servers
silver
129.21.38.145
129.21.37.175
7/17/2015
129.21.30.254
mordor-37
kiev
staff
129.21.39.254
ICL2
ICL3
CSL
Internet Protocol
mordor
60
Kiev ifconfig
kiev> ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 129.21.38.145 netmask ffffff80 broadcast 129.21.38.255
kiev>
7/17/2015
Internet Protocol
61
Mordor ifconfig
mordor> ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 129.21.30.26 netmask ffffff80 broadcast 129.21.30.127
qfe0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 129.21.37.218 netmask ffffff80 broadcast 129.21.37.255
qfe1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 129.21.38.218 netmask ffffff80 broadcast 129.21.38.255
qfe2: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 129.21.39.218 netmask ffffff80 broadcast 129.21.39.255
mordor>
7/17/2015
Internet Protocol
62
Grace ifconfig
$ ifconfig -a
tu0: flags=c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
fta0: flags=8c63<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,SIMPLEX>
inet 129.21.3.102 netmask ffffff00 broadcast 129.21.3.255 ipmtu 4352
sl0: flags=10<POINTOPOINT>
lo0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
inet 127.0.0.1 netmask ff000000 ipmtu 4096
7/17/2015
Internet Protocol
63
Kiev netstat
kiev> netstat -rn
Routing Table:
Destination
-------------------129.21.38.128
224.0.0.0
default
127.0.0.1
kiev>
7/17/2015
Gateway
Flags Ref
Use
Interface
-------------------- ----- ----- ------ --------129.21.38.145
U
3
3056 hme0
129.21.38.145
U
3
0 hme0
129.21.38.254
UG
0 21129
127.0.0.1
UH
0 21718 lo0
Internet Protocol
64
Mordor netstat
mordor> netstat -rn
Routing Table:
Destination
-------------------129.21.30.0
129.21.37.128
129.21.38.128
129.21.39.128
224.0.0.0
default
127.0.0.1
mordor>
7/17/2015
Gateway
Flags Ref
Use
Interface
-------------------- ----- ----- ------ --------129.21.30.26
U
3
374 hme0
129.21.37.218
U
2
2667 qfe0
129.21.38.218
U
2
2858 qfe1
129.21.39.218
U
2
1967 qfe2
129.21.30.26
U
3
0 hme0
129.21.30.126
UG
0
4762
127.0.0.1
UH
08072949 lo0
Internet Protocol
65
traceroute
kiev> traceroute silver
traceroute: Warning: ckecksums disabled
traceroute to silver (129.21.37.175), 30 hops max, 40 byte packets
1 cs3-router (129.21.38.254) 0.716 ms 0.513 ms 0.523 ms
2 silver (129.21.37.175) 1.703 ms * 0.988 ms
kiev> traceroute mordor
traceroute: Warning: ckecksums disabled
traceroute to mordor (129.21.30.26), 30 hops max, 40 byte packets
1 cs3-router (129.21.38.254) 0.635 ms 0.496 ms 0.527 ms
2 mordor-38 (129.21.38.218) 0.590 ms * 0.746 ms
kiev> traceroute mordor-38
traceroute: Warning: ckecksums disabled
traceroute to mordor-38 (129.21.38.218), 30 hops max, 40 byte packets
1 mordor-38 (129.21.38.218) 0.558 ms * 0.457 ms
kiev>
7/17/2015
Internet Protocol
66
traceroute
kiev> traceroute grace
traceroute: Warning: ckecksums disabled
traceroute to grace.rit.edu (129.21.3.102), 30 hops max, 40 byte packets
1 cs3-router (129.21.38.254) 0.730 ms 0.572 ms 0.442 ms
2 grace.isc.rit.edu (129.21.3.102) 0.794 ms 0.724 ms 0.697 ms
kiev>
$ traceroute kiev.cs.rit.edu
traceroute to kiev.cs.rit.edu (129.21.38.145), 30 hops max, 40 byte packets
1 r33.isc.rit.edu (129.21.3.217) 1 ms 1 ms 0 ms
2 kiev.cs.rit.edu (129.21.38.145) 1 ms * 1 ms
$
7/17/2015
Internet Protocol
67
PTT-net
• Recently got Road Runner
• Unhappy about reports of constant probes of
machines
• Policy decision
– I want to prevent unauthorized probes/connection
attempts on my machines
• Mechanism
– Purchase some sort of firewall for my home network
7/17/2015
Internet Protocol
68
DI-701
Manufacturer: D-Link (www.dlink.com)
7/17/2015
Internet Protocol
69
Configuration
Desktop
Internet
Cable Modem
DI-701
Hub
Laptop
Printer
7/17/2015
Internet Protocol
70
Address Management
RR-DHCP
(24.93.24.121)
Internet
Cable Modem
Desktop
DI-701
Hub
DLINK (192.168.0.1)
Laptop
Printer
DLINK-DHCP
(192.168.0.2 – 192.168.0.32)
7/17/2015
Internet Protocol
71
Firewall
Internet traffic stops here
Internet
Cable Modem
Desktop
DI-701
Filters Internet traffic…
Hub
Laptop
Printer
Addresses never go
past firewall
7/17/2015
Internet Protocol
72
BCP-5
• The Internet has grown beyond anyone's
expectations. Sustained exponential growth…
• One challenge is that globally unique address
space will be exhausted.
• A separate and far more pressing concern is that
the amount of routing overhead will grow beyond
the capabilities of Internet Service Providers.
• Efforts are in progress to find long term solutions
to both of these problems.
7/17/2015
Internet Protocol
73
Types of Hosts
• Hosts using IP can be grouped into 3 categories:
– Category 1
• Hosts that do not require access to hosts in other enterprises or
the Internet at large
– Category 2
• Hosts that need access to a limited set of outside services
which can be handled by mediating gateways. For many hosts
in this category an unrestricted external access may be
unnecessary and even undesirable for security reasons.
– Category 3:
• Hosts that need network layer access outside the enterprise
(provided via IP connectivity)
7/17/2015
Internet Protocol
74
Ramifications
• Hosts using IP can be grouped into 3 categories:
– Category 1
• IP addresses need to be unambiguous within an enterprise, but
may be ambiguous between enterprises.
– Category 2
• Just like hosts within the first category, hosts may use IP
addresses that are unambiguous within an enterprise, but may
be ambiguous between enterprises.
– Category 3:
• Requires IP addresses that are globally unambiguous.
7/17/2015
Internet Protocol
75
PTT-net
• PTT-net clearly falls into category 1 or 2
– Assuming the DI-701 is doing its job
• The Internet Assigned Numbers Authority (IANA)
has reserved the following three blocks of the IP
address space for private internets:
– 10.0.0.0 - 10.255.255.255
– 172.16.0.0 - 172.31.255.255
– 192.168.0.0 - 192.168.255.255
7/17/2015
Internet Protocol
76
Mystery
• PTT’s laptop opens a TCP connection to the CS
department’s web server
–
–
–
–
–
–
–
7/17/2015
Laptop’s address is 192.168.0.2:1234
Destination is 129.21.30.29:80
Routed to DI-701
DI-701 replaces with address with 24.93.24.121
RIT responds, destination 24.93.24.121
Arrives at DI-701
How does the DI-702 know the send the packet to the
laptop?
Internet Protocol
77
Mystery Solved
Private Address
Private Port
External
Address
External Port
NAT
Port
Protocol
Used
192.168.0.2
1234
129.21.30.21
80
14003
TCP
192.1.68.0.1
386
129.2.1.30.21
80
14004
TCP
192.168.0.2
5000
129.21.30.24
25
14005
TCP
192.168.0.1
5000
129.21.30.24
25
14006
TCP
7/17/2015
Internet Protocol
78
Network Address Translator
• NAT is a method by which IP addresses are
mapped from one realm to another
• NAT devices connect an isolated address realm to
a realm with globally unique registered addresses
• There are a variety of flavors of NAT and terms to
match them
• RFC-2663 is an attempt to define NAT
7/17/2015
Internet Protocol
79
Common Characteristics
• All flavors of NAT devices should share the
following characteristics.
– Transparent Address assignment.
– Transparent routing through address translation.
(routing here refers to forwarding packets, and not
exchanging routing information)
– ICMP error packet payload translation.
7/17/2015
Internet Protocol
80
Basic Idea
• NAT devices attempt to provide transparent
routing
– Source/Destination addresses are modified en-route
– The NAT device maintains state so that the datagrams
are routed to the correct end-node
– This solution works only when the applications do not
use the IP addresses as part of the protocol itself
7/17/2015
Internet Protocol
81
Translation
• TCP/UDP sessions are uniquely identified by the
tuple
– (source-IP, source-port, dest-IP, dest-port)
• ICMP query sessions are identified by
– (source-IP, ICMP query ID, dest-IP)
• All other sessions
– (source-IP, dest-IP, IP protocol)
7/17/2015
Internet Protocol
82
Start of Session
• TCP
– The first packet of every sessions contains a SYN bit
and no ACK bit
– All other TCP packets will have the ACK bit set
• UDP
– No deterministic way to determine the start of a session
– Assume the first packet with never before seen
parameters marks the start of a session
7/17/2015
Internet Protocol
83
IP Futures
• There are problems with IP which are a result of
the phenomenal growth of the Internet over the
past few years
– as of 1994, over half of the class B addresses have been
allocated
– 32-bit IP addresses are inadequate
– the current routing structure is basically flat, making
routing tables too large
• CDIR fixes the last problem for a while
7/17/2015
Internet Protocol
84
New IP Versions
• Four proposals have been made for a new version
of IP
– SIP, the Simple Internet Protocol. Proposes a minimal
set of changes to IP that uses 64-bit addresses and a
different header format
– PIP, larger, variable length, hierarchical addresses with
a different header format
– TUBA (RFC1347), TCP and UDP with bigger
addresses
– TP/IX (RFC1475), 64-bit addresses, changes TCP/UDP
7/17/2015
Internet Protocol
85
References
• The May 1993 issue of IEEE Network (volume 7,
number 3) contains overviews of the first three
proposals, along with an article on CDIR.
• RFC1454 also compares the first three proposals
7/17/2015
Internet Protocol
86