1 / 34

Addressing: IPv4, IPv6, and Beyond

Addressing: IPv4, IPv6, and Beyond. CS 4251: Computer Networking II Nick Feamster Spring 2008. 10000010. 11001111. 00000111. 00100100. IPv4 Addresses: Networks of Networks. Topological Addressing. 32-bit number in “dotted-quad” notation www.cc.gatech.edu --- 130.207.7.36. 130. 207. 7.

aquene
Télécharger la présentation

Addressing: IPv4, IPv6, and Beyond

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Addressing: IPv4, IPv6, and Beyond CS 4251: Computer Networking IINick FeamsterSpring 2008

  2. 10000010 11001111 00000111 00100100 IPv4 Addresses: Networks of Networks Topological Addressing • 32-bit number in “dotted-quad” notation • www.cc.gatech.edu --- 130.207.7.36 130 207 7 36 Network (16 bits) Host (16 bits) • 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

  3. Pre-1994: Classful Addressing 32 8 16 24 Class A Network ID 0 Host ID • /8 blocks (e.g., MIT has 18.0.0.0/8) Class B 10 • /16 blocks (e.g., Georgia Tech has 130.207.0.0/16) Class C 110 • /24 blocks (e.g., AT&T Labs has 192.20.225.0/24) Class D Multicast Addresses 1110 Class E Reserved for experiments 1111 Simple Forwarding: Address range specifies network ID length

  4. 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

  5. Routing Table Growth: Who Cares? • On pace to run out of allocations entirely • Memory • Routing tables • Forwarding tables • “Churn”: More prefixes, more updates

  6. Possible Solutions • Get rid of global addresses • NAT • Get more addresses • IPv6 • Different aggregation strategy • Classless Interdomain routing

  7. 01000001 00001110 11111000 00000000 11111111 11111111 11111100 00000000 Classless Interdomain Routing (CIDR) Use two 32-bit numbers to represent a network. Network number = IP address + Mask Example: BellSouth Prefix: 65.14.248.0/22 IP Address: 65.14.248.0 “Mask”: 255.255.252.0 Address no longer specifies network ID range.New forwarding trick: Longest Prefix Match

  8. 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 12.20.231.0/24 12.0.0.0/8 AT&T Internet Customer 2 12.20.249.0/24

  9. 1994-1998: Linear Growth • About 10,000 new entries per year • In theory, less instability at the edges (why?) Source: Geoff Huston

  10. Around 2000: Fast Growth Resumes T. Hain, “A Pragmatic Report on IPv4 Address Space Consumption”, Cisco IPJ, September 2005 Claim: remaining /8s will be exhausted within the next 5-10 years.

  11. Fast growth resumes Significant contributor: Multihoming Dot-Bomb Hiccup Rapid growth in routing tables Source: Geoff Huston

  12. Multihoming Can Stymie Aggregation Verizon does not “own” 10.0.0.0/16. Must advertise the more-specific route. • “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 12.20.249.0/24 12.20.249.0/24 Mid-Atlantic Corporate Federal Credit Union (AS 30308)

  13. The Address Allocation Process • Allocation policies of RIRs affect pressure on IPv4 address space IANA http://www.iana.org/assignments/ipv4-address-space AfriNIC APNIC ARIN LACNIC RIPE Georgia Tech

  14. /8 Allocations from IANA • MIT, Ford, Halliburton, Boeing, Merck • Reclaiming space is difficult. A /8 is a bargaining chip!

  15. Address Space Ownership % whois -h whois.arin.net 130.207.7.36 [Querying whois.arin.net] [whois.arin.net] OrgName: Georgia Institute of Technology OrgID: GIT Address: 258 Fourth St NW Address: Rich Building City: Atlanta StateProv: GA PostalCode: 30332 Country: US NetRange: 130.207.0.0 - 130.207.255.255 CIDR: 130.207.0.0/16 NetName: GIT NetHandle: NET-130-207-0-0-1 Parent: NET-130-0-0-0-0 NetType: Direct Assignment NameServer: TROLL-GW.GATECH.EDU NameServer: GATECH.EDU Comment: RegDate: 1988-10-10 Updated: 2000-02-01 RTechHandle: ZG19-ARIN RTechName: Georgia Institute of TechnologyNetwork Services RTechPhone: +1-404-894-5508 RTechEmail: hostmaster@gatech.edu OrgTechHandle: NETWO653-ARIN OrgTechName: Network Operations OrgTechPhone: +1-404-894-4669 • - Regional Internet Registries (“RIRs”) • - Public record of address allocations • - ISPs should update when delegating address space • - Often out-of-date

  16. 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

  17. Header Formats IPv4

  18. 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)

  19. 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)

  20. IPv6 Flows • Traffic can be labeled with particular flow identifier for which a sender can expect special handling (e.g., different priority level)

  21. IPv6: Deployment Options Routing Infrastructure • IPv4 Tunnels • Dual-stack • Dedicated Links • MPLS Applications • IPv6-to-IPv4 NAPT • Dual-stack servers

  22. IPv6 Deployment Status Big users: Germany (33%), EU (24%), Japan (16%), Australia (16%)

  23. 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

  24. Transitioning: IPv6 over IPv4 Tunnels One trick for mapping IPv6 addresses: embed the IPv4 address in low bits http://www.cisco.com/en/US/tech/tk872/technologies_white_paper09186a00800c9907.shtml

  25. 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

  26. 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

  27. 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

  28. 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, …)

  29. 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

  30. 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

  31. 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

  32. Application Use SID as handle App session Bind to EID Transport IP hdr EID TCP SID … IP The Naming Layers User-level descriptors(e.g., search) App-specific search/lookup returns SID App session Resolves SID to EIDOpens transport conns Transport Resolves EID to IP IP

  33. 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”

  34. Flat Names: Flexible Migration • SID abstracts all object reachability information • Objects: any granularity (files, directories) • Benefit: Links (referrers) don’t break Domain H HTTP GET: /docs/pub.pdf 10.1.2.3 <A HREF= http://f012012/pub.pdf >here is a paper</A> /docs/ HTTP GET: /~user/pubs/pub.pdf Domain Y 20.2.4.6 (10.1.2.3,80, /docs/) /~user/pubs/ (20.2.4.6,80, /~user/pubs/) ResolutionService

More Related