NAT and DHCP

• When global connectivity is not required

• -> Only local communication enough…

=> local network

=> private network where only one or more gateways are (globally) visible

• private IP addresses

• 10.0.0.0/8

• 172.16.0.0/12

• 192.168.0.0/16

• NO

• -> private IP address ranges only need to be unique locally

• network address translation

• map many local IP addresses to one single public IP address

• => IP Masquerading

• => Port Address Translation (PAT)

• => Network Address and Port Translation (NAPT)

• No -> impossible

• NAT only holds information about active connections that it translates…

• => cannot establish new connection from outside…

• no, even ones belonging to active connections

• -> have to be filterd and relaed by the NAT router

• Breaks TCP/IP semantic

• => only translates IP header and not rest

• => i.e. ftp uses IP address in protocol -> is not translated in NAT…

• NAT more efficient use of public address range

  • making more extensive use of IP addresses and their respective port numbers

• NAT translates many local IP addresses to one global IP address that are only distinguishable by the use of other ports, or few global IP addresses

• NAT always used as proxy

• local computer cannot be reached by other computer (without additional configuration)

• source IP

• TTL

• header checksum

• destination IP

• IPv4 to IPv6

• IPv6 to IPv4

• file transfer protocol

• Dynamic host configuration protocol

• computer to learn about their network config

  • subnet mask

  • defaukt gateway

  • IP address

  • DNS servers

  • lease duration

• dynamically

• out of pool of pre-specified IP addresses

• -> can be reassigned later (if not statically assigned)

• DHCPDISCOVER

• DHCPOFFER

• DHCPREQUEST

• DHCPACK

• DHCPNACK

• DHCPDECLINE

• DHCPRELEASE

• DHCPINFORM

• client broadcast to locate available servers

• server to client response to dhcp discover

• with offering of config parameters

• client to serverS either

  • (a) request offered parameters frome one server and implicity decline offers from all other servers

  • (b) confirm correctnes of previously allocated address after e.g. system reboot

  • (c) extend lease on particular network address

• server to client

• with config parameters including commited network address (that are acknowledged after the request)

• server to client

• indicate cluents notion of network address is incorrect

• => e.g. client has moved to new subnet,, or clients lease is expired…

• client to server

• offered IP already in use

• client to server

• relinquish network address and calcel remaining lease

• client to server

• ask only for local config paraeters

• -> client already has externally configured network address…

• dhcp ack message

• communicate dhcp messages between client and server in different subnets

• used where presence of dedicated dhcp server on each physical network segment not viable/preferred

• op (opcode/message type)

• htpye (hardware address type)

• hlen (hardware address length , e.g. 6 for ethernet)

• hops (usually set to 0 by client, used by dhcp relay agents)

• xid (transaction id)

• secs (filled by client, secods since began address acquisition)

• flags (flags…)

• ciaddr (client ip address (if bound, renew or rebinding) -> only when already has ip)

• yiaddr (new IP address for client -> “your ip address))

• siadr (ip address of dhcp server, returned in dhcp offer and dhcp ack)

• giaddr (ip address of relay agent)

• chaddr (client hardware address)

• sname (server host name)

• file (boot file name)

• options

• transaction id

• random number chosen by client

• used to associate messages and responses sent by server and clietn

• subnet mask

• broadcast address

• domain name

• domain name server

• host name

• yes

• -> client msut adhere to same client ip for all subsequent messsages after first use

wrong

• same parameters as in the dhcp offer

• combination of

  • chaddr

  • client ID

  • bound network address (of client)

• udp

• 53 (message type)

• -> mandatory in every dhcp message…

• including them in dhcp options

• Basic functinlaity covered by slaac (ip adderess assignment)

• -> DHCPv6 can nevertheless be used for:

  • dns informaitno

  • ntp server

  • etc.

  • also offers stateful adress config

• set managed-flag in router advertisement

• no -> only offer…

• can still use slaac

• ff02::1:2

• ff05::1:3

• cliients as well as servers have unique DUID

• prefix delegation

• provider edge (router)

• customer premise equipment (router)

• -> PE managed by ISP and delegatin prefixes to CPE that can advertise them (SLAAC; DHCPv6,…)

• no

• has to be cncluded in dhcpv6 messages

• timers indicating when lifetime of requested prefixes should be refreshed

• IA_DP contains requested prefixes and contains information such as validity timters for prefix

• no

• no

• no

• delegating: DHCP server

• receiving: DHCP client

• in bulk, not a single address…

• equivalent to the IA for address

• yes

• -> include them in IA_PDs

• IAID for all specific IA_PDs of requesting router must be unique

• no

• container for rules

  • basechain -> entry point for packets from networking stack

  • regular chain -> jump target (better rule organization)

• filter

• nat

• route

• hooks call base chains located in hooks

• -> define at which point in packet lifecycle the rules are called and thus packets processed via nftables

• prerouting

• input

• forward

• output

• postrouting

• filtering packets before packet reaches routing system of os

• => every pacet that enters the system… (also used to change packet attributes affecting the routing process)

• filtering packets after the routing decisions of the os

• => every packet about to leave the system

• port address translation

• maps port numbers to private ip addresses

• => allows for single public IP…

  
  

• ICMP has no port numbers…

• use ICMP’s id to map incoming echo replies to specific IP address

• => outgoing ICMP echo request id gets translated by NAT to be unique… (in case it has to handle more than one…)

• => has thus also to recalculate ICMP header checksum

• ftp has active or passive mode

• -> active mode: ftp server establishes connection back to client… => works not in NAT as address and port is in payload (and thus not changed by NAT rotuer)

• => ftp server returns illegal port command (as PORT command contains privaet ip in payload…)

• => use passive mode

• passive mode: client establishes connection to server

• active server establishes connection to client

• client sends PASV command

• server respons with IP and prot client should connect to

• client connects

• 4

• client sends DHCP discover (to find dhcp servers)

• server responds with DHCP offer (to offer IP address)

• client replies to offer with DHCP request (again broadcast and same addresses as in dhcp discover) (actively request offered things)

• server acknowledges with DHCP ACK (IP still free to use and client now allowed to take ut)

• DHCP avoids assigning same IP to different hotst

• -> if only discover and offer -> dhcp does not know what is taken…

• -> if only discover, offer and request -> two clients could request the same…

• potentially

• -> might still have valid lease file.( not timed out…)

• => DCHP discover contains additional option (50) requested iP address that re-requests ip fro previous lease…)

• renew

• rebind

• expire

• usually 50% of lease time

• when 0 -> client transits to renewal state

• tries to renew lease by sending DHCP request

• if succeees -> DHCP server answers with dhcp ack

• usually 75% of lease time

• when 0 (e.g. dhcp server not acknowledging)

• client transisitno to rebinding state

• tries to renew lease by sendoing out DHCP requests

• broadcast not unicast like in renew state to reach and DHCP server

• undo dhcp based configs

• -> have to start dhcp process from the beginning…

• server UDP 67

• client UDP 68

• dhcp bases on bootp (makes use of well known ports)

• => lecagy: BOOTP uses broadcast to assign IP to client

• => if client use arbitrary port (1025-60565)

• => might happen that other client coincidentially also listents to this port…

• => confusing it with unexpected message…

• identity associatoin for prefix delegation

• groutp together, identify and manage set of related IPv6 prefixes

• between requesting and delegating router

• => uniquely identified by IAID (identity association id)

• can be bound to client, multiple interface, or one interface

• in regular solicitations -> IA_PD included (with associated IAID)

• dhcp server sends advertisement -> assigns prefix address to IA_PD from solicitation

  • contains additional data

    • T1, T2 timers

    • IA_PD data length

    • prefix lenght

    • valid lifetime

• client then again requests the assigned prefix

• and server then replies again containing the same information…

• solicitation -> all dhcp servers

• request -> client includes the server identifier (wih unique server id DUID)

• t1: when 0 client expected to contact server that did assignment to extend lifetome of address assigned

• t2: contacy any dhcp client to renew

• tries to rebind using lesae file

• provides client identifier as wel as IA_ID including prefixes client associates with IA_PD

• => delegating router checks IP_PD in rebind message

  • wether prefxes in IA_PD are contained in binding entry corresponding to the requestin router..

• if not: return prefix with lifetimes set to 0 else send with updated lifetimes…

• DHCP to share regular informatino (an no addresses)

• => dhcp server does not have to keep track whom it shared information with…

• i.e. dns informatino, …

• dhcp unique identifier

• -> used to uniquely identify things in dhcp

• can be:

  • link layer address plus time

  • vendor assigned unique ID

  • link layer address

  • universally unique identifier

• more efficient use of address space

  • e.g. use unrouted addresses, address trading

• create more addresses

  • IPv6

• address sharing

  • NAT (and dhcp)

• costly

• opaque, transactions nit public

• deployment…

• -> requires end-to-end support

  • server side: content providers

  • network path: ISP and transit providers

  • client-side: content consumers

• => still in process…

• anyone can use these UP address ranges in their own network

• addresses are not routed in the public Internet

• Internet access through address translation → NAT

• RFC 1918 reserves the following IPv4 address ranges

  • 10.0.0.0/8

  • 172.16.0.0/12

  • 192.168.0.0/16

• RFC 6598 reserves an additional range for ISP networks

  • 100.64.0.0/10

• RFC 4193 specifies Unique Local IPv6 addresses

  • fc00::/7

• sits in-beetween private network and internet (router…)

• -> outgoing packets: replace private IP with public one and change source port to a unique one to identify incoming packets

• -> incoming packets: lookup the dst port and then map the dest IP to the private IP

• NAT table

• -> hold global endpoint (IP and PORT that replaced the private iP and the port)

• -> and local endpoint (Private IP and port used by the host in the private network )

• => in one row…

• today the majority of end users are located behind NAT (+ other middleboxes)

• no standardization of NAT → many different implementations

• transparent to the public Internet

• effectively saves IP addresses: allows ∼65,000 simultaneous flows with a single public IP address

• address independence: public/private IP addresses can be changed independently

• topology hiding: devices inside local network are not explicitly addressable/visible from outside

• connections can only be established from the local network

• ports should not be used to address hosts

• routers should not manipulate packets above layer 2 (end-to-end principle)

• server located in the local network

  • any service behind NAT, peer-to-peer applications

• realm-specific IP address information in payload

  • e.g. SIP, FTP

• bundled session applications

  • protocols using multiple connections, e.g. active FTP

• unsupported protocols

  • e.g. SCTP, IPsec

• port forwarding

• application layer gateway (ALG)

• hole punching

• create static entry in NAT table (manually or via protocol) that allows to reach a host specified by the entry…

• => requires support in NAT and end hosts

• nat analyzes and rewrites application layer protocols (e.g. FTP, where IP and Port are specified in the payload…)

• requires support for every protocol in the NAT device

• two clients behind NAT try to estbailsh connection

• -> exists rendez-vous server (i.e. with static IP)

• -> both clients establish connection with rendez-vous server

• -> server transmits IP and port from session with client 2 to client 1 and vice versa

• client 1 and client 2 send trash message to the received IP and port => respective NAT creates entries for established connection and lets incoming stuff through…

• !!! Requires consistent translations so that port is reused…

• similar to hole punching

• -> establish connetion to relay server

• => communication happens over relay server

• => disadvantage: latency and bandwidht (potential bottleneck)

• ongoing

• -> ISP still need to provide IPv4 functionality

• extend lifetime of IPv4: Carrier grade NAT

• or choose between large scale NAT vs aqusition of more Ipv4 addresses

• i.e. ISP in cellular networks assigns private IP to end devices and has NAT inbetwen them and internet

• type of large scale nat

• -> where i.e. two lines of NAT

• dual stack lite

• 464XLAT

• combines global IPv6 and carrier grade NAT

• -> ISP assigns private IPv4 and global IPv6 to customer premise equipemnt

• customer has private IPv4

• CLAT (translates IPv4 to IPv6) to communicate over ISP network

• ISP has PLAT that then translates IPv6 to IP4 again to communicate with internet (NAT64 and DNS64)

• IPv6 to IPv4 using PLAT

• IPv6 to IPv6 direct

=> translation done with stateless IP/ICMP translation (SIIT)

• slows down adoption of IPv6

• will be around until no one uses IPv4 anymore

• limited control over NAT function (e.g. no port forwarding)

• multiple customers share same pubblic IP address

  • hampers criminal prosecution based on IP address

• customers can interfere wich each otehr

  • number of concurrent connectoins

• logging each mapping is expensive

  • bulk port allocation

• manual network config of hosts not scalable

• automated configuration of network parameters e.g. IP addresses, subnets, gateway, DNS server, etc.

• UDP-based client-server protocol

• servers lease IP addresses to clients for a certain amount of time

• stateful server, can make decisions based on client history

• extensible through DHCP options

• UDP protocol on top of IPv4 (server port 67, client port 68)

• uses IPv4 broadcast packets

• discover message: client announces its presence in the network (L2 broadcast)

• offer message: server(s) make a lease offer to the client.

• request message: client accepts an offer and requests the offered configuration (L2 broadcast)

  • implicitly denies offers of other servers

  • is also used to extend the lease of a currently used configuration

• acknowledge message: server leases a configuration to the client

• UDP protocol on top of IPv6 (server port 547, client port 546)

• protocol sequence similar to DHCPv4

• uses IPv6 multicast packets

• uses DHCP Unique Identifiers (DUIDs) to identify the client instead of MAC addresses

• DHCPv6 can complement SLAAC or completely replace it

• DHCPv6 provides more configuration parameters than SLAAC (and can easily be extended) e.g. DNS server configuration: router advertisements require RDNSS extension (RFC6106), not supported by all clients

• DHCPv6 allows fine-grained control over the allocated addresses and centralized address logging

• ISP assign /48 to customer, /64 in mobile entworks

• No Authentication of DHCP-Server

• No Authentication of Clients