Addressing: IPv4, IPv6, and Beyond
description
Transcript of Addressing: IPv4, IPv6, and Beyond
![Page 1: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/1.jpg)
Addressing: IPv4, IPv6, and Beyond
CS 4251: Computer Networking IINick FeamsterSpring 2008
![Page 2: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/2.jpg)
IPv4 Addresses: Networks of Networks
• 32-bit number in “dotted-quad” notation
– www.cc.gatech.edu --- 130.207.7.36
10000010 11001111 00000111 00100100
Network (16 bits) Host (16 bits)
130 207 7 36
• Problem: 232 addresses is a lot of table entries
• Solution: Routing based on network and host
– 130.207.0.0/16 is a 16-bit prefix with 216 IP addresses
Topological Addressing
![Page 3: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/3.jpg)
Pre-1994: Classful Addressing
Network ID Host ID
8 16
Class A
32
0
Class B 10
Class C 110
Multicast AddressesClass D 1110
Reserved for experimentsClass E 1111
24
/8 blocks (e.g., MIT has 18.0.0.0/8)
/16 blocks (e.g., Georgia Tech has 130.207.0.0/16)
/24 blocks (e.g., AT&T Labs has 192.20.225.0/24)
Simple Forwarding: Address range specifies network ID length
![Page 4: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/4.jpg)
Problem: Routing Table Growth
• Growth rates exceeding advances in hardware and software capabilities
• Primarily due to Class C space exhaustion• Exhaustion of routing table space was on the horizon
Source: Geoff Huston
![Page 5: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/5.jpg)
Routing Table Growth: Who Cares?
• On pace to run out of allocations entirely
• Memory– Routing tables – Forwarding tables
• “Churn”: More prefixes, more updates
![Page 6: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/6.jpg)
Possible Solutions
• Get rid of global addresses– NAT
• Get more addresses– IPv6
• Different aggregation strategy– Classless Interdomain routing
![Page 7: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/7.jpg)
Classless Interdomain Routing (CIDR)
IP Address: 65.14.248.0 “Mask”: 255.255.252.0
01000001 00001110 11111000 00000000
11111111 11111111 11111100 00000000
Use two 32-bit numbers to represent a network. Network number = IP address + Mask
Example: BellSouth Prefix: 65.14.248.0/22
Address no longer specifies network ID range.New forwarding trick: Longest Prefix Match
![Page 8: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/8.jpg)
Benefits of CIDR
• Efficiency: Can allocate blocks of prefixes on a finer granularity
• Hierarchy: Prefixes can be aggregated into supernets. (Not always done. Typically not, in fact.)
Customer 1
Customer 2
AT&T Internet
12.20.249.0/24
12.20.231.0/2412.0.0.0/8
![Page 9: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/9.jpg)
1994-1998: Linear Growth
• About 10,000 new entries per year• In theory, less instability at the edges (why?)
Source: Geoff Huston
![Page 10: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/10.jpg)
Around 2000: Fast Growth Resumes
Claim: remaining /8s will be exhausted within the next 5-10 years.
T. Hain, “A Pragmatic Report on IPv4 Address Space Consumption”, Cisco IPJ, September 2005
![Page 11: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/11.jpg)
Fast growth resumes
Rapid growth in routing tables
Dot-Bomb Hiccup
Significant contributor: Multihoming
Source: Geoff Huston
![Page 12: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/12.jpg)
Multihoming Can Stymie Aggregation
• “Stub AS” gets IP address space from one of its providers• One (or both) providers cannot aggregate the prefix
12.20.249.0/24
AT&T Verizon
Verizon does not “own” 10.0.0.0/16. Must advertise
the more-specific route.
Mid-Atlantic Corporate Federal
Credit Union (AS 30308)
12.20.249.0/24
12.20.249.0/24
![Page 13: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/13.jpg)
The Address Allocation Process
• Allocation policies of RIRs affect pressure on IPv4 address space
IANA
AfriNIC APNIC ARIN LACNIC RIPE
http://www.iana.org/assignments/ipv4-address-space
Georgia Tech
![Page 14: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/14.jpg)
/8 Allocations from IANA
• MIT, Ford, Halliburton, Boeing, Merck• Reclaiming space is difficult. A /8 is a bargaining chip!
![Page 15: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/15.jpg)
Address Space Ownership% whois -h whois.arin.net 130.207.7.36[Querying whois.arin.net][whois.arin.net]
OrgName: Georgia Institute of TechnologyOrgID: GITAddress: 258 Fourth St NWAddress: Rich BuildingCity: AtlantaStateProv: GAPostalCode: 30332Country: US
NetRange: 130.207.0.0 - 130.207.255.255CIDR: 130.207.0.0/16NetName: GITNetHandle: NET-130-207-0-0-1Parent: NET-130-0-0-0-0NetType: Direct AssignmentNameServer: TROLL-GW.GATECH.EDUNameServer: GATECH.EDUComment:RegDate: 1988-10-10Updated: 2000-02-01
RTechHandle: ZG19-ARINRTechName: Georgia Institute of TechnologyNetwork ServicesRTechPhone: +1-404-894-5508RTechEmail: [email protected]
OrgTechHandle: NETWO653-ARINOrgTechName: Network OperationsOrgTechPhone: +1-404-894-4669
- Regional Internet Registries (“RIRs”)- Public record of address allocations- ISPs should update when delegating address space- Often out-of-date
![Page 16: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/16.jpg)
IPv6 and Address Space Scarcity
• 128-bit addresses– Top 48-bits: Public Routing Topology (PRT)
• 3 bits for aggregation• 13 bits for TLA (like “tier-1 ISPs”)• 8 reserved bits• 24 bits for NLA
– 16-bit Site Identifier: aggregation within an AS– 64-bit Interface ID: 48-bit Ethernet + 16 more bits
– Pure provider-based addressing• Changing ISPs requires renumbering
![Page 17: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/17.jpg)
Header Formats
IPv4
![Page 18: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/18.jpg)
Summary of Fields
• Version (4 bits) – only field to keep same position and name• Class (8 bits) – new field• Flow Label (20 bits) – new field• Payload Length (16 bits) – length of data, slightly different from
total length• Next Header (8 bits) – type of the next header, new idea• Hop Limit (8 bits) – was time-to-live, renamed• Source address (128 bits)• Destination address (128 bits)
![Page 19: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/19.jpg)
IPv6: Claimed Benefits
• Larger address space• Simplified header• Deeper hierarchy and policies for network
architecture flexibility • Support for route aggregation • Easier renumbering and multihoming• Security (e.g., IPv6 Cryptographic Extensions)
![Page 20: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/20.jpg)
IPv6 Flows
• Traffic can be labeled with particular flow identifier for which a sender can expect special handling (e.g., different priority level)
![Page 21: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/21.jpg)
IPv6: Deployment Options
• IPv4 Tunnels• Dual-stack• Dedicated Links• MPLS
Routing Infrastructure
Applications
• IPv6-to-IPv4 NAPT• Dual-stack servers
![Page 22: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/22.jpg)
IPv6 Deployment Status
Big users: Germany (33%), EU (24%), Japan (16%), Australia (16%)
![Page 23: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/23.jpg)
Transitioning: Dual-Stack
• Dual-Stack Approach: Some nodes can send both IPv4 and IPv6 packets– Dual-stack nodes must determine whether a node is
IPv6-capable or not– When communicating with an IPv4 node, an IPv4
datagram must be used
![Page 24: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/24.jpg)
Transitioning: IPv6 over IPv4 Tunnels
http://www.cisco.com/en/US/tech/tk872/technologies_white_paper09186a00800c9907.shtml
One trick for mapping IPv6 addresses: embed the IPv4 address in low bits
![Page 25: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/25.jpg)
Reality: “96 More Bits, No Magic”
• No real thought given to operational transition• IPv6 is not compatible with IPv4 on the wire
– Variable-length addressing could have fixed this, but…
• Routing load won’t necessarily be reduced– TE Model is the same– Address space fragmentation will still exist
• The space is not infinite: 64 bits to every LAN• Not necessarily better security• Routers don’t fully support all IPv6 features in hardware
![Page 26: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/26.jpg)
Another extension: Security (IPSec)
• Backwards compatible with IPv4• Transport mode: Can be deployed only at
endpoints (no deployment at routers needed)– Encrypted IP payload encapsulated within an
additional, ordinary IP datagram
• Provides– Encryption of datagram– Data Integrity– Origin authentication
![Page 27: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/27.jpg)
Architectural Discontents
• Lack of features– End-to-end QoS, host control over routing, end-to-
end multicast,…
• Lack of protection and accountability– Denial-of-service (DoS)
• Architecture is brittle
![Page 28: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/28.jpg)
Architectural Brittleness
• Hosts are tied to IP addresses– Mobility and multi-homing pose problems
• Services are tied to hosts– A service is more than just one host: replication,
migration, composition
• Packets might require processing at intermediaries before reaching destination– “Middleboxes” (NATs, firewalls, …)
![Page 29: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/29.jpg)
Internet Naming is Host-Centric
• Two global namespaces: DNS and IP addresses
• These namespaces are host-centric– IP addresses: network location of host– DNS names: domain of host– Both closely tied to an underlying structure– Motivated by host-centric applications
![Page 30: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/30.jpg)
Trouble with Host-Centric Names
• Host-centric names are fragile– If a name is based on mutable properties of its
referent, it is fragile– Example: If Joe’s Web page
www.berkeley.edu/~hippie moves to www.wallstreetstiffs.com/~yuppie, Web links to his page break
• Fragile names constrain movement– IP addresses are not stable host names– DNS URLs are not stable data names
![Page 31: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/31.jpg)
Solution: Name Services and Hosts Separately
• Service identifiers (SIDs) are host-independent data names
• End-point identifiers (EIDs) are location-independent host names
• Protocols bind to names, and resolve them– Apps should use SIDs as data handles– Transport connections should bind to EIDs
![Page 32: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/32.jpg)
The Naming Layers
User-level descriptors(e.g., search)
App session
App-specific search/lookupreturns SID
Transport
Resolves SID to EIDOpens transport conns
IP
Resolves EID to IP
Bind to EID
Use SID as handle
IP hdr EID TCP SID …IP
Transport
App session
Application
![Page 33: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/33.jpg)
SIDs and EIDs should be Flat
• Flat names impose no structure on entities– Structured names stable only if name structure matches
natural structure of entities– Can be resolved scalably using, e.g., DHTs
• Flat names can be used to name anything– Once you have a large flat namespace, you never need
other global “handles”
![Page 34: Addressing: IPv4, IPv6, and Beyond](https://reader030.fdocuments.us/reader030/viewer/2022012905/5681537d550346895dc180c1/html5/thumbnails/34.jpg)
ResolutionService
Flat Names: Flexible Migration
<A HREF=http://f012012/pub.pdf>here is a paper</A>
<A HREF=http://f012012/pub.pdf>here is a paper</A>
HTTP GET:
/docs/pub.pdf
10.1.2.3
/docs/
20.2.4.6
HTTP GET:
/~user/pubs/pub.pdf(10.1.2.3,80,/docs/)(20.2.4.6,80,
/~user/pubs/)/~user/pubs/
• SID abstracts all object reachability information• Objects: any granularity (files, directories)• Benefit: Links (referrers) don’t break
Domain H
Domain Y