EPL606 Internetworking Part 2c 1 IP Internet Concatenation of - - PowerPoint PPT Presentation

▶
epl606
SMART_READER_LITE
LIVE PREVIEW

EPL606 Internetworking Part 2c 1 IP Internet Concatenation of - - PowerPoint PPT Presentation

Nov 30, 2023 307 likes •707 views

EPL606 Internetworking Part 2c 1 IP Internet Concatenation of Networks Network 1 (Ethernet) H7 R3 H8 H1 H2 H3 Network 4 (point-to-point) Network 2 (Ethernet) R1 R2 H4 Network 3 (FDDI) Protocol Stack H6 H5 H1 H8 TCP

slide-1
SLIDE 1

EPL606

Internetworking Part 2c

1

slide-2
SLIDE 2

IP Internet

  • Concatenation of Networks
  • Protocol Stack

2

R2 R1 H4 H5 H3 H2 H1 Network 2 (Ethernet) Network 1 (Ethernet) H6 Network 4 (point-to-point) H7 R3 H8 Network 3 (FDDI)

R1 R2 R3 H1 H8 ETH FDDI IP ETH TCP FDDI PPP PPP ETH IP ETH TCP IP IP IP

slide-3
SLIDE 3

Datagram Forwarding

  • Strategy

 every datagram contains destination’s address  if connected to destination network, then forward to host  if not directly connected, then forward to some router  forwarding table maps network number into next hop  each host has a default router  each router maintains a forwarding table

  • Example (R2)

Network Number Next Hop 1 R3 2 R1 3 interface 1 4 interface 0

3

slide-4
SLIDE 4

Address Translation

  • Map IP addresses into physical addresses

 destination host  next hop router

  • Techniques

 encode physical address in host part of IP address  table-based

  • ARP

 table of IP to physical address bindings  broadcast request if IP address not in table  target machine responds with its physical address  table entries are discarded if not refreshed

4

slide-5
SLIDE 5

ARP– The Address Resolution Protocol

Three interconnected /24 networks: two Ethernets and an FDDI ring.

slide-6
SLIDE 6

ARP Details

  • Request Format

 HardwareType: type of physical network (e.g., Ethernet)  ProtocolType: type of higher layer protocol (e.g., IP)  HLEN & PLEN: length of physical and protocol addresses  Operation: request or response  Source/Target-Physical/Protocol addresses

  • Notes

 table entries timeout in about 10 minutes  update table with source when you are the target  update table if already have an entry  do not refresh table entries upon reference

6

slide-7
SLIDE 7

ARP Packet Format

7

TargetHardwareAddr (bytes 2 5) TargetProtocolAddr (bytes 0 3) SourceProtocolAddr (bytes 2 3) Hardware type = 1 ProtocolType = 0x0800 SourceHardwareAddr (bytes 4 5) TargetHardwareAddr (bytes 0 1) SourceProtocolAddr (bytes 0 1) HLen = 48 PLen = 32 Operation SourceHardwareAddr (bytes 0 ― 3) 8 16 31 ― ― ― ― ― ―

slide-8
SLIDE 8

Internet Control Message Protocol (ICMP)

  • Echo (ping)
  • Redirect (from router to source host)
  • Destination unreachable (protocol, port, or host)
  • TTL exceeded (so datagrams don’t cycle forever)
  • Checksum failed
  • Reassembly failed
  • Cannot fragment

8

slide-9
SLIDE 9

NAT: network address translation

Network Layer

4-9

10.0.0.1 10.0.0.2 10.0.0.3 10.0.0.4 138.76.29.7

local network (e.g., home network) 10.0.0/24 rest of Internet datagrams with source or destination in this network have 10.0.0/24 address for source, destination (as usual) all datagrams leaving local network have same single source NAT IP address: 138.76.29.7,different source port numbers

slide-10
SLIDE 10

NAT: network address translation

motivation: local network uses just one IP address as far as outside world is concerned:

  • range of addresses not needed from ISP:

just one IP address for all devices

  • can change addresses of devices in local

network without notifying outside world

  • can change ISP without changing

addresses of devices in local network

  • devices inside local net not explicitly

addressable, visible by outside world (a security plus)

Network Layer

4-10

slide-11
SLIDE 11

NAT: network address translation

implementation: NAT router must:

  • outgoing datagrams: replace (source IP address, port #)
  • f every outgoing datagram to (NAT IP address, new

port #)

. . . remote clients/servers will respond using (NAT IP address, new port #) as destination addr

  • remember (in NAT translation table) every (source IP

address, port #) to (NAT IP address, new port #) translation pair

  • incoming datagrams: replace (NAT IP address, new port

#) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table

Network Layer

4-11

slide-12
SLIDE 12

NAT: network address translation

4-12

10.0.0.1 10.0.0.2 10.0.0.3

S: 10.0.0.1, 3345 D: 128.119.40.186, 80

1

10.0.0.4 138.76.29.7

1: host 10.0.0.1 sends datagram to 128.119.40.186, 80 NAT translation table WAN side addr LAN side addr

138.76.29.7, 5001 10.0.0.1, 3345 …… ……

S: 128.119.40.186, 80 D: 10.0.0.1, 3345

4

S: 138.76.29.7, 5001 D: 128.119.40.186, 80

2 2: NAT router changes datagram source addr from 10.0.0.1, 3345 to 138.76.29.7, 5001, updates table

S: 128.119.40.186, 80 D: 138.76.29.7, 5001

3 3: reply arrives

  • dest. address:

138.76.29.7, 5001 4: NAT router changes datagram dest addr from 138.76.29.7, 5001 to 10.0.0.1, 3345

slide-13
SLIDE 13

NAT: network address translation

  • 16-bit port-number field:

 60,000 simultaneous connections with a single LAN-side address!

  • NAT is controversial:

 routers should only process up to layer 3  violates end-to-end argument

 NAT possibility must be taken into account by app designers, e.g., P2P applications

 address shortage should instead be solved by IPv6

Network Layer

4-13

slide-14
SLIDE 14

NAT traversal problem

  • client wants to connect

to server with address 10.0.0.1

 server address 10.0.0.1 local to LAN (client can’t use it as destination addr)  only one externally visible NATed address: 138.76.29.7

  • solution1: statically

configure NAT to forward incoming connection requests at given port to server

 e.g., (123.76.29.7, port 2500) always forwarded to 10.0.0.1 port 25000

Network Layer

4-14

10.0.0.1 10.0.0.4

NAT router

138.76.29.7

client

?

slide-15
SLIDE 15

NAT traversal problem

solution 2: Universal

Plug and Play (UPnP) Internet Gateway Device (IGD) Protocol. Allows NATed host to:

 learn public IP address

(138.76.29.7)

 add/remove port

mappings (with lease times) i.e., automate static NAT port map configuration

Network Layer

4-15

10.0.0.1

NAT router IGD

slide-16
SLIDE 16

NAT traversal problem

solution 3: relaying (used in Skype)

  • NATed client establishes connection to relay
  • external client connects to relay
  • relay bridges packets between to connections

Network Layer

4-16

138.76.29.7

client

  • 1. connection

to relay initiated by NATed host

  • 2. connection

to relay initiated by client

  • 3. relaying

established NAT router

10.0.0.1

slide-17
SLIDE 17

ICMP: internet control message protocol

  • used by hosts & routers to

communicate network- level information

 error reporting: unreachable host, network, port, protocol  echo request/reply (used by ping)

  • network-layer “above”

IP:

 ICMP msgs carried in IP datagrams

  • ICMP message: type, code

plus first 8 bytes of IP datagram causing error

Type Code description 0 0 echo reply (ping) 3 0 dest. network unreachable 3 1 dest host unreachable 3 2 dest protocol unreachable 3 3 dest port unreachable 3 6 dest network unknown 3 7 dest host unknown 4 0 source quench (congestion control - not used) 8 0 echo request (ping) 9 0 route advertisement 10 0 router discovery 11 0 TTL expired 12 0 bad IP header

Network Layer

4-17

slide-18
SLIDE 18

Traceroute and ICMP

  • source sends series of

UDP segments to dest

 first set has TTL =1  second set has TTL=2, etc.  unlikely port number

  • when nth set of

datagrams arrives to nth router:

 router discards datagrams  and sends source ICMP messages (type 11, code 0)  ICMP messages includes name of router & IP address

  • when ICMP messages

arrives, source records RTTs

  • stopping criteria:

 UDP segment eventually arrives at destination host  destination returns ICMP “port unreachable” message (type 3, code 3)  source stops

Network Layer

4-18

3 probes 3 probes 3 probes

slide-19
SLIDE 19

Next Generation IP (IPv6)

Network Layer

19

slide-20
SLIDE 20

Network Layer

20

Size of the Internet

1000 2000 3000 4000 5000 6000 1 9 8 8 1 9 8 9 1 9 9 1 9 9 1 1 9 9 2 1 9 9 3 1 9 9 4 1 9 9 5 1 9 9 6 1 9 9 7 1 9 9 8 1 9 9 9 2 2 1 2 2 2 3 2 4 2 5 2 6 2 7

Theoretical Usable

IPv4 Doomsday ?

  • Approx. 27% remain unallocated

Distribution Statement A: Cleared for Public Release; Distribution is unlimited.

slide-21
SLIDE 21

Network Layer

21

Internet BGP Routing Table

Exponential Growth No Growth Linear Growth CIDR deployment Exponential Growth - CIDR breaking down

http://www.telstra.net/ops/bgptable.html

Distribution Statement A: Cleared for Public Release; Distribution is unlimited.

slide-22
SLIDE 22

Network Layer

22 What about technologies & efforts to slow the consumption rate?

  • Dial-access / PPP / DHCP

Provides temporary allocation aligned with actual endpoint use.

  • Strict allocation policies

Reduced allocation rates by policy of ‘current-need’ vs. previous policy based on ‘projected-maximum-size’.

  • CIDR

Aligns routing table size with needs-based address allocation

  • policy. Additional enforced aggregation actually lowered

routing table growth rate to linear for a few years.

  • NAT

Hides many nodes behind limited set of public addresses.

slide-23
SLIDE 23

Network Layer

23 What did intense conservation efforts of the last 5 years buy us?

  • Actual allocation history

1981 – IPv4 protocol published 1985 ~ 1/16 total space 1990 ~ 1/8 total space 1995 ~ 1/4 total space 2000 ~ 1/2 total space

  • The lifetime-extending efforts & technologies

delivered the ability to absorb the dramatic growth in consumer demand during the late 90’s. In short they bought – TIME –

slide-24
SLIDE 24

Network Layer

24

Would increased use of NATs be adequate?

NO!

  • NAT enforces a ‘client-server’ application model where the server has

topological constraints.

  • They won’t work for peer-to-peer or devices that are “called” by others

(e.g., IP phones)

  • They inhibit deployment of new applications and services, because all

NATs in the path have to be upgraded BEFORE the application can be deployed.

  • NAT compromises the performance, robustness, and security of the

Internet.

  • NAT increases complexity and reduces manageability of the local

network.

  • Public address consumption is still rising even with current NAT

deployments.

slide-25
SLIDE 25

Network Layer

25

78 Top Level IPv6 ISPs in 26 Countries

APNIC ARIN RIPE

2 4 6 8 10 12 14 16

J a p a n U n i t e d S t a t e s S . K

  • r

e a G e r m a n y S w e d e n U K E u r

  • p

e F r a n c e R u s s i a P

  • l

a n d N e t h e r l a n d s F i n l a n d T a i w a n C h i n a & H K C a n a d a M e x i c

  • A

u s t r i a S w i t z e r l a n d G r e e c e P

  • r

t u g a l B e l g i u m I t a l y D e n m a r k N

  • r

w a y A u s t r a l i a S i n g a p

  • r

e

Distribution Statement A: Cleared for Public Release; Distribution is unlimited.

slide-26
SLIDE 26

Network Layer

26

78 Top Level IPv6 ISPs in 22 months

RIPE APNIC ARIN

10 20 30 40 50 60 70 80 90 100

Jul-99 Aug-99 Sep-99 Oct-99 Nov-99 Dec-99 Jan-00 Feb-00 Mar-00 Apr-00 May-00 Jun-00 Jul-00 Aug-00 Sep-00 Oct-00 Nov-00 Dec-00 Jan-01 Feb-01 Mar-01 Apr-01 May-01

Distribution Statement A: Cleared for Public Release; Distribution is unlimited.

slide-27
SLIDE 27

Network Layer

27

What Ever Happened to IPv5?

IP March 1977 version (deprecated) 1 IP January 1978 version (deprecated) 2 IP February 1978 version A (deprecated) 3 IP February 1978 version B (deprecated) 4 IPv4 September 1981 version (current widespread) 5 ST Stream Transport (not a new IP, little use) 6 IPv6 December 1998 version (formerly SIP, SIPP) 7 CATNIP IPng evaluation (formerly TP/IX; deprecated) 8 Pip IPng evaluation (deprecated) 9 TUBA IPng evaluation (deprecated) 10-15 unassigned

slide-28
SLIDE 28

Network Layer

28

Benefits of 128 bit Addresses

  • Room for many levels of structured hierarchy

and routing aggregation

  • Easy address auto-configuration
  • Easier address management and delegation

than IPv4

  • Ability to deploy end-to-end IPsec

(NATs removed as unnecessary)

slide-29
SLIDE 29

Network Layer

29

Incidental Benefits of New Deployment

  • Chance to eliminate some complexity in IP header

 improve per-hop processing

  • Chance to upgrade functionality

 multicast, QoS, mobility

  • Chance to include new features

 binding updates

slide-30
SLIDE 30

Network Layer

30

IPv6 Enhancements (1)

  • Expanded address space

 128 bit

  • Improved option mechanism

 Separate optional headers between IPv6 header and transport layer header  Most are not examined by intermediate routes

 Improved speed and simplified router processing  Easier to extend options

  • Address autoconfiguration

 Dynamic assignment of addresses

slide-31
SLIDE 31

Network Layer

31

IPv6 Enhancements (2)

  • Increased addressing flexibility

 Anycast - delivered to one of a set of nodes  Improved scalability of multicast addresses

  • Support for resource allocation

 Replaces type of service  Labeling of packets to particular traffic flow  Allows special handling  e.g. real time video

slide-32
SLIDE 32

Network Layer

32

Summary of Main IPv6 Benefits

  • Expanded addressing capabilities
  • Structured hierarchy to manage routing table growth
  • Serverless autoconfiguration and reconfiguration
  • Streamlined header format and flow identification
  • Improved support for options / extensions
slide-33
SLIDE 33

Network Layer

33

Types of address

  • Unicast

 Single interface

  • Anycast

 Set of interfaces (typically different nodes)  Delivered to any one interface  the “nearest”

  • Multicast

 Set of interfaces  Delivered to all interfaces identified

slide-34
SLIDE 34

Network Layer

34

IPv6 Addressing

  • Classless addressing/routing (similar to CIDR)
  • Notation: x:x:x:x:x:x:x:x (x = 16-bit hex number)

 contiguous 0s are compressed: 47CD::A456:0124  IPv6 compatible IPv4 address: ::128.42.1.87

  • Address assignment

 provider-based (can’t change provider easily)  geographic

010 Registry ID Provider ID Subscriber ID Subnet ID Interface ID n bits m bits

  • bits

p bits (125-m-n-o-p) bits

slide-35
SLIDE 35

The Main IPv6 Header

  • The IPv6 fixed header (required).

Network Layer

35

slide-36
SLIDE 36

Network Layer

36

IPv6 Header (Cont)

Priority: identify priority among datagrams in flow Flow Label: identify datagrams in same “flow.” (concept of“flow” not well defined). Next header: identify upper layer protocol for data Checksum: removed entirely to reduce processing time at each hop Options: allowed, but outside of header, indicated by “Next Header” field ICMPv6: new version of ICMP additional message types, e.g. “Packet Too Big” multicast group management functions

Changes from IPv4

slide-37
SLIDE 37

Network Layer

37

Extension Headers

IPv6 extension headers. 5-69

slide-38
SLIDE 38

Transition from IPv4 to IPv6

  • not all routers can be upgraded simultaneously

 no “flag days”  how will network operate with mixed IPv4 and IPv6 routers?

  • tunneling: IPv6 datagram carried as payload in

IPv4 datagram among IPv4 routers

Network Layer

4-38

IPv4 source, dest addr IPv4 header fields

IPv4 datagram IPv6 datagram

IPv4 payload UDP/TCP payload IPv6 source dest addr IPv6 header fields