Lecture 9: DHCP and IPv6 DHCP Autoconfiguration BOOTP

Lecture 9: DHCP and IPv6 DHCP Autoconfiguration BOOTP
Internetworking
Lecture 9: DHCP and IPv6
DHCP
Literature:
Forouzan, TCP/IP Protocol Suite: Ch 16, 27
lecture_9
lecture_9
Autoconfiguration
• Need a way to simply connect a computer to a new network
– No manual configuration
• But each computer attached to a TCP/IP network must know the
following:
– Its IP address and subnet mask
– The IP address of a router (default gateway)
– The IP address of a name server
– Extra info: default TTL, time servers, etc.
• We have talked about RARP, to translate MAC Æ IP addr
– But, RARP needs direct access to the (ethernet) hardware
– It only contains an IP address
BOOTP – Bootstrap Protocol
• BOOTP (RFC 951) is a lot more powerful than RARP
• Client/Server Protocol
• Designed to provide the previously mentioned pieces of
information (and more)
• BOOTP sends requests/replies over UDP
– Easy to write a user space server
– Client does not need a full TCP/IP stack to run BOOTP
• But BOOTP is not dynamic
– uses a static binding between MAC and IP addresses
– Requires fixed hw addresses
• BOOTP and DHCP solve these problems.
– Client/Server architecture
lecture_9
– UDP/IP
lecture_9
DHCP (RFC 1531)
DHCP – Dynamic Host Configuration Protocol
• DHCP provides dynamic configuration
– Client can get a temporary address, and move from network to
network
• DHCP is backward compatible with BOOTP
– BOOTP client can request a static configuration from a DHCP
server
lecture_9
DHCP Operation
1. DHCP server uses UDP port no 67 and waits for client
2. Client sends requests encapsulated in UDP using:
•
dst IP address 255.255.255.255
•
dst port no 67
•
src IP address 0.0.0.0
•
src port no 68
3. Server replies with either broadcast or unicast message
using UDP destination port 68
•
The unicast IP address of the client can be used in server’s reply
message if client’s IP address has been manually added in the
ARP table
•
Note that the server will know the client’s MAC address
lecture_9
1
DHCP simplified example
Well-known DHCP Port Numbers
Note that DHCP does not use ephemeral port number at
the client side.
• The reply from the server can be broadcast
• Broadcast response will reach all hosts on the subnet
• It is considered bad manner to broadcast to a random port
number
Server
Client
Broadcast
67
68
Request
UDP
UDP
68
67
Reply
UDP
UDP
IP datagram
UDP datagram
IP header
UDP header
DHCP request/reply
20 bytes
8 bytes
300 bytes
What if two clients are using DHCP simultaneously?
• The Transaction ID will help recognizing the reply message
• Transaction ID is chosen randomly
lecture_9
lecture_9
Relay Agent
DHCP Message Header
0
• A relay agent (proxy) is used so a DHCP server can serve several
subnets
78
Operation Code
– A relay agent is a router that sends local requests to a remote server,
and relays replies back to the subnet.
15 16
32
23 24
Hardware Type
Hardware Length
Transaction ID
Number of Seconds
B
Client IP Address
Your IP Address
Server IP Address
Hop Count
Unused
Gateway IP Address
Relay agent
Client
Server
Client Hardware Address (16 bytes)
Broadcast
67
68
UDP
Request
Server Name (64 bytes)
UDP
Boot File Name (128 bytes)
68
67
Reply
UDP
UDP
lecture_9
Options (variable)
lecture_9
DHCP Message fields
•
Opcode:
Request (1), Reply (2)
•
Hardware type:
1 for Ehernet (cf ARP)
•
Hardware address len:
6 for Ethernet
•
Hop Count
+1 for each relay forwarder (proxy)
•
Transaction ID
•
•
•
DHCP Options and message types
•
Lots of semantics implemented in the DHCP options field
•
Uses ”TLV”: Type-Length-Value
set by client to identify session
•
Subnetmask
B-flag
forced broadcast reply
•
Address of routers, nameservers, timeservers, hostname, etc.
# seconds
time since boottime of client
•
Message type examples
client IP address
If client knows its address
•
your IP address
Client address set by server
•
server IP address
Server address filled in by server
•
gateway IP address
Proxy server address
– DHCPREQUEST
•
client hardware address
Set by client (same as SA in eth header)
– DHCPACK
•
server hostname
Set by server
– DHCPNACK
•
boot filename
Set by server for bootstrapping
– DHCPRELEASE
•
options
Variable length (up to 312 bytes)
lecture_9
– or ”Vendor-specific field”
type
length
value
– DHCPDISCOVER
– DHCPOFFER
lecture_9
2
DHCP Initialization
• First discover a server, then request address lease
DHCP Expiration
• After 50% of lease, client need to renew
• If server NACKs, client needs to start over immediately (shown below)
• If server does not respond, client continues until lease expires
Server
Client
Server
Client
67
68
DHCPDISCOVER
67
68
DHCPOFFER
DHCPREQUEST
DHCPREQUEST
DHCPREQUEST
DHCPACK
DHCPNACK
DHCPRELEASE
lecture_9
lecture_9
DHCP Client
• Message type option specifies DHCP
Message
DHCP’s Importance
• DHCP client runs in user space
• Allows reuse of address, which avoids having to tie up
addresses for systems which are not currently connected to
the Internet
This transition is missing in
Forouzan!
• Avoids user configuration of IP address (avoids mistakes
and effort)
• Allows recycling of an IP address when devices are
scrapped
DHCPNACK
lecture_9
©The McGraw-Hill Companies, Inc., 2000
lecture_9
IPv6
• Changes since IPv4 was developed (mid 70’s)
– Provider market has changed dramatically
– Immense increase in user and traffic on the Internet
IPv6 and ICMPv6
– Rapid technology advancement
– Bandwidth increase from kb/s to Tb/s
• IPv4 issues
The Next Generation
– Too few addresses (though only 3-7% of address space used)
– Too large routing tables
• To address these issuees IETF has standardized IPv6
– IPv6 should keep most of the characteristics of IPv4 (good design)
– Changing the address fields is the big thing with IPv6
– While modifying the header, improvements have been introduced
lecture_9
lecture_9
3
IPv6 vs IPv4
IPv6 Simplifications
• Changes in IPv6 compared to IPv4
• Fixed format headers
– 128 bit addresses
– Use extension headers instead of options
– extended address hierarchy
– simplified header
• Remove header checksum
– simpler and better support for options
– Rely on link layer and higher layers to check integrity of data
– possible to extend the protocol
– support for autoconfiguration (plug-and-play)
• Remove hop-by-hop segmentation
– support for QoS treatment
– Fragmentation only by sender due to path MTU discovery
– host mobility
– security
– provider selection
– no fragmentation in routers
lecture_9
lecture_9
IPv6 Header Format
0
15 16
4-bit
Version
8-bit
Class
IPv4 vs IPv6 Header
31
1. Header length removed
20-bit Flow Label
16-bit Payload Length
8-bit
Next Header
8-bit
Hop Limit
2. ToS Æ Class + Flow label
40 bytes
128-bit Source Address
3. Total length ÆPayload Length
4. Identification, flags and offset are removed
128-bit Destination Address
•
Version
Only field identical to IPv4. Code is 6 in IPv6
•
Class
New field. Revised concept of priority bits. Facilitates handling of real-time traffic.
•
Flow Label
New field. To distinguish packets requiring the same treatment.
•
Payload Length Replaces length field in IPv4. Gives length of data following IPv6 header
•
Next Header
Replaces protocol field in IPv4. Extension headers can be used.
•
Hop Limit
Replaces TTL field in IPv4. Hop limit more accurately reflects the use of TTL.
•
Src Address
Revised source address field. 128 bits in IPv6 vs 32 bits in IPv4.
•
Dst Address
Revised destination address field. 128 bits in IPv6 vs 32 bits in IPv4.
lecture_9
•
Fragmentation extension header
5. TTL Æ Hop limit
6. Protocol Æ Next Header
7. Header checksum removed
8. Options Æ Extension headers
lecture_9
IPv6 Addresses
IPv6 address
• An IPv6 unicast address identifies an interface connected to an IP
subnet (as is the case in IPv4)
• One big difference between IPv6 and IPv4 is that IPv6 routinely allows
each interface to be identified by several addresses
• Colon hexadecimal notation (eight 16 bit hexadecimal integers)
– facilitates management
• IPv6 has three address categories:
– unicast - identifies exactly one interface
– multicast - identifies a group; packets get delivered to all members of the
group
– anycast - identifies a group; packets normally get delivered to nearest
member of the group
• 128 bits results in
2128
©The McGraw-Hill Companies, Inc., 2000
addresses
– Distributed over the Earth: 665,570,793,348,866,943,898,599/m2
– Pessimistic estimate with hierarchies: ~1,564 addresses/m2
lecture_9
lecture_9
4
Address abbreviations and CIDR
Initial Address Allocation (Oct 2002)
Prefix
• Leading zeros may be oppressed
– FDEC:BA98:0074:3210:000F:BBFF:0000:FFFF Æ
– FDEC:BA98:74:3210:F:BBFF:0:FFFF
• Zero compression: one of a series of zeros may be replaced by ::
– But only once
– FDEC:0:0:0:0:BBFF:0:FFFF Æ
– FDEC::BBFF:0:FFFF
• CIDR notation to specify the first N bits of an address
– FDEC:0:0:0:0:BBFF:0:FFFF/60
lecture_9
lecture_9
General Unicast Addresses
Fraction of space
Allocation
0000 0000
1/256
Unassigned (some address formats)
0000 0001
1/256
Unassigned
0000 001
1/128
NSAP allocation
0000 01
1/64
Unassigned
0000 1
1/32
Unassigned
0001
1/16
Unassigned
001
1/8
Global Unicast Addresses
010
1/8
Unassigned
011
1/8
Unassigned
100
1/8
Unassigned
101
1/8
Unassigned
110
1/8
Unassigned
1110
1/16
Unassigned
1111 0
1/32
Unassigned
1111 10
1/64
Unassigned
1111 110
1/128
Unassigned
1111 1110 0
1/512
Unassigned
1111 1110 10
1/1024
Link Local Unicast Addresses
1111 1110 11
1/1024
Site Local Unicast Addresses
1111 1111
1/256
Multicast Addresses
Global Unicast Addresses (001b)
General format for IPv6 global unicast addresses:
Global Routing Prefix
n bits
48 bits
Subnet ID
Interface ID
m bits
128-n-m bits
MAC addr
Global Routing Prefix
• Global Routing Prefix
– typically hierarchically structured value assigned to a site (cluster of
subnets/links)
• Subnet ID
– identifier of a link within the site
• Interface ID
– if prefix starts with binary 000: no constraint on Interface ID structure
– otherwise: a globally unique EUI-64 address, (can be derived from 48-bit
Ethernet address)
n bits
Subnet ID
Interface ID
64-n bits
64 bits
• 001b prefix
– 64 bit network-id (global prefix typically /32)
– 64 bit interface-id
• MAC-derived Interface ID
– Globally unique EUI-64 address,
– Derived from 48-bit IEEE 802 address
– Insert FF:FF in the middle two bytes.
– L3ÆL2 address resolution automatic
lecture_9
lecture_9
Privacy Extensions RFC 3041
• MAC-derived interface-ids is an easy way to ensure unique addresses
– And get rid of L2/L3 address resolution
• But, you know many things about the origin of the packet
– IEEE 802 addresses have encoded data
• The identity and vendor of the interface card
• You can derive which equipment you use
• E.g., exploit bugs in that equipment
– You can track the node when netid is changed (dhcp/mobile IP)
• Mac-derived interface ids
Special Address Formats
The following special addresses are allocated from prefix 0000 0000:
• Unspecified Address (0:0:0:0:0:0:0:0:0)
– only used as source address during bootstrap by a computer that has not
yet learned its address
• Loopback Address (0:0:0:0:0:0:0:0:1)
– used for testing software (compare with IPv4 loopback address 127.0.0.1)
• IPv6 Addresses with Embedded IPv4 Addresses
– Needed during transition from IPv4 to IPv6 (checksum calculation
unaffected)
– Randomly assigned interface-id
– Changes over time
• Protects users
• You need to make L2/L3 address resolution
lecture_9
0000.............0000
0000
IPv4 Address
0000.............0000 FFFF
IPv4 Address
80 bits
16 bits
32 bits
0000 – IPv4-compatible IPv6 address:
to dynamically tunnel IPv6 packets
over IPv4 routing infrastructure
FFFF – IPv4-mapped IPv6 address:
to represent the address of IPv4
nodes as IPv6 addresses
lecture_9
5
Link-local unicast address
• Link-Local addresses - for use on a single link
Site-local unicast address
• Site-local addresses – for use on a single site
– For purposes such as automatic address configuration, neighbour
discovery, isolated network
• Routers do not forward packets using link-local addresses
– For purposes such as private or nonroutable addressing
• Routers do not forward site-local addresses outside the site
• Now obsolete
1111111010
0000...0000
Interface ID
1111111011
Subnet ID
Interface ID
10 bits
54 bits
64 bits
10 bits
54 bits
64 bits
lecture_9
lecture_9
Multicast Addresses
Predefined Multicast Addresses
• Permanent: assigned by IANA
Some predefined mcast addresses:
• Scope Example: assume NTP servers have a group ID of 101:
• All nodes multicast
– FF02::101 means all NTP servers on the same link as the sender
– FF05::101 means all NTP servers in the same site as the sender
– FF0E::101 means all NTP servers in the Internet
– FF01::1 (interface-local)
– FF02::1 (link-local)
– In IPv4 224.0.0.1 is used
• All routers multicast
– FF01::2 (interface-local)
– FF02::2 (link-local)
– FF05::2 (site-local)
– In IPv4 224.0.0.2 is used
lecture_9
©The McGraw-Hill Companies, Inc., 2000
lecture_9
Anycast Addresses
• Sending a packet to a generic address to get a specific service from the
“nearest” instance. This puts the burden of determining which instance
to deliver it to on the routing system.
• According to IPv6 Addressing Architecture Draft
– An anycast address is an address assigned to more than one interface
(typically different nodes)
– Anycast addresses are allocated from the unicast address space
– Nodes must be explicitly configured to know an address is an anycast
address
Current IPv6 address allocation
• IANA + Regional Internet Registries (RIR) only allocates 0012
addresses
• Currently (2003) 480 prefixes allocated
• 94% of these prefixes are /32.
• From current 6bone BGP routing table statistics, it can be noted that
only 2% of the prefixes are longer than /48 [7].
• Expected use:
– identify the set of routers belonging to a service provider
– identify the set of routers providing an entry into a particular routing domain
• Restrictions (until more experience has been gained):
– An anycast address must not be used as source address of an IPv6 packet
– An anycast address must not be assigned to an IPv6 host, only to an IPv6
router
lecture_9
lecture_9
6
Extension Headers
Extension headers are linked
• To give more functionality to IP, extension headers have
been introduced in IPv6
• Several of the IPv6 extension headers are options in IPv4
• Extension headers are placed between the IPv6 base
header and the transport level header (TCP/UDP)
IPv6 Header, Next = TCP
TCP Header + Data
IPv6 Header, Next = Route
Routing Header, Next = TCP
• Next headers come in a linked list
• Can be hard to parse: need an iterative process
TCP Header + Data
lecture_9
lecture_9
Extension header types
©The McGraw-Hill Companies, Inc., 2000
Extension Headers
• Hop-by-hop Options header
Hop-by-hop options header
– TLV coded options processed by every hop along the path
– Jumbo payload option for pkt > 65535 bytes (RFC 2675)
Routing header
– Router alert option (RFC 2711)
• Fragment header
Fragment header
Extension
Headers
Authentication header
– Only source can fragment packets in IPv6
– Source must use Path MTU Discovery (RFC 1981) or send max 536
bytes payload
– Fragmentation information
• Fragmentation offset shifted (as in IPv4)
Encapsulated security payload header
• Fragmentation ID is 32 bits (16 bits in IPv4)
• No DF flag (present in IPv4, but not needed in IPv6)
Destination options header
lecture_9
lecture_9
Extension headers, cont’d
• Routing header
Autoconfiguration (Plug-and-Play)
• Address resolution
– Strict or loose source routing
– ICMP has been revised along with the development of IPv4 Æ IPv6
– Similar to the IPv4 Source route and Record route options
– IPv6 does not use ARP but a neighbour detection scheme based on
ICMPv6
• Authentication header (IPSEC)
– to validate the message sender and ensure integrity of data
• Encapsulated Security Payload header (IPSEC)
– to provide confidentiality and guard against eavesdropping
• Destination Options header
• Stateful configuration (managed)
– Flag in router advertisement tells whether to rely on
autoconfiguration or to use conventional managed configuration
(DHCP)
• Stateless autoconfiguration / Serverless
– TLV coded options processed by destination only
lecture_9
lecture_9
7
Stateless autoconfiguration
Real-Time Support and Flows
8-bit Class
• Use link-local address and interface ID
20-bit Flow ID
• Hosts join all-nodes mcast address (FF02::1)
• Hosts communicate to routers using all-routers mcast
address (FF02::2)
• ICMPv6 router solicitation sent by host to request additional
information
• ICMPv6 router advertisement sent by router to inform host
about prefixes for site and global addresses
lecture_9
•
Flow ID field: used by a source to label sequences of packets for which it
requests special handling by the IPv6 routers
•
Class field: available for use by originating nodes and/or forwarding routers to
identify and distinguish between different classes or priorities of IPv6 packets
•
The use of these fields is still experimental, and subject to change as the
requirements become clearer
•
Flow ID assigned to a flow by the flow’s source node
•
All packets belonging to the same flow must be sent with the same src addr, dst
addr, and flow label
•
RSVP or other mechanism needed for resource reservation
•
Real-time data transfers require protocols such as RTP in addition to IPv6
lecture_9
Network Layer Comparison - v4 vs
v6
ICMPv4 vs ICMPv6
ICMPv4 has been modified to be more suitable for IPv6, and thus updated to
ICMPv6
Ver 4
Ver 6
Destination unreachable
Yes
Yes
•
ARP and IGMP in version 4 are now part of ICMPv6
Source quench
Yes
No
•
RARP has been dropped due to limited use (DHCP does the job of RARP)
Packet too big
No
Yes
•
As in ICMPv4, ICMPv6 messages are divided into 2 categories:
•
Error Report Message – Type
Time exceeded
Yes
Yes
– Error-reporting (somewhat different messages in v6 vs v4, see following slide)
Parameter problem
Yes
Yes
– Query (rather different messages in v6 vs v4, see following slide)
Redirection
Yes
Yes
Ver 4
Ver 6
Echo request and reply
Query Message – Type
Yes
Yes
Timestamp request and reply
Yes
No
Address mask request and reply
Yes
No
Router solicitation and advertisement
Yes
Yes
Neighbour solicitation and advertisement
ARP
Yes
Group membership
IGMP
Yes
©The McGraw-Hill Companies, Inc., 2000
lecture_9
lecture_9
Transition from IPv4 to IPv6
• Because of the large number of systems on the Internet,
the transition from IPv4 to IPv6 cannot happen suddenly
• Transition should be smooth to prevent problems
• Three transition strategies have been devised by IETF
Dual Stack
• All hosts have dual stack of protocols until all of the Internet runs IPv6
• To determine which version to use, the source host queries the DNS
Transition
Strategies
Dual Stack
lecture_9
Tunneling
Header Translation
lecture_9
©The McGraw-Hill Companies, Inc., 2000
8
Transition from IPv4 to IPv6
IPv6 Summary
• IPv6 has:
IPv4
Internet
– 128-bit address space
– revised header format
IPv6 tunnel
– new options
– allowance for extension
• Tunnel appear as a virtual link between IPv6 nodes
• Encapsulation of IPv6 packets in IPv4
– support for special handling of packet flows
– increased security measures
• IPv6 uses hexadecimal colon notation with abbreviation methods
• IPv6 has three address types: unicast, anycast, and multicast
lecture_9
20 bytes
40 bytes
IPv4
header
IPv6
header
• IPv4, ICMPv4, ARP, RARP, and IGMP replaced with IPv6 and ICMPv6
IPv6
payload
• IPv4 to IPv6 transition strategies are based on dual-stack and tunneling
lecture_9
9
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising