Your SlideShare is downloading. ×
Upcoming Internet challenges<br />Ivan Pepelnjak (ip@nil.com)NIL Data Communications<br />
The big three (from my perspective)<br />IPv4 address exhaustion<br />Routing table explosion<br />Traffic growth (or mayb...
IPv4 address exhaustion<br />Source: IPv4 address report (Geoff Huston, www.potaroo.net)<br />
IPv4 address exhaustion: solutions<br />Walled gardens<br />NAT444<br />DS-Lite/A+P<br />IPv6<br />
IPv4-only NAT options<br />CPE<br />CPE<br />Baseline:NAT44<br />RFC1918<br />IPv4 ProviderPrivate<br />IPv4 Internet<br /...
NAT options: DS-Lite or A+P<br />CPE<br />B4<br />DS-Lite<br />RFC1918<br />AFTR<br />IPv4 Internet<br />IPv4 Internet<br ...
NAT-less IPv4 4ever<br />AFTR<br />IPv4 Internet<br />IPv6<br />A+P on the host<br />Native IPv6 for transport only<br />T...
Complexities of NAT<br />IPv6 does not require NAT<br /><ul><li>Public IPv6 addresses only
Simple P2P session setup
Both hosts must be IPv6-enabled</li></ul>198.51.100.22<br />198.51.100.22<br />10.0.0.2<br />10.0.0.2<br />10.0.0.2<br />1...
Requests to server come from public IP address
Problem: protocols with embedded addresses (FTP, SIP)</li></ul>Network Address Translation (NAT)<br /><ul><li>Maps private...
Requires outbound session setup
P2P applications with NAT are a nightmare
End-to-end connectivity might not be possible
Fallback: public relay servers</li></li></ul><li>What is IPv6?<br />DNS<br />Web, Mail<br />DHCP<br />UDP<br />TCP<br />IP...
Longer addresses, new routing protocols, some other changes in L2/L3 protocols
Upper layers and applications should not change</li></li></ul><li>IPv6 adoption: the “ivory-tower” beliefs<br />Who caresa...
IPv6 adoption: the unpleasant reality<br />IPv6 adoption [%]<br />IPv6-onlyclients?<br />NAT and RFC 1918<br />IPv6 pilots...
Enterprise customer connectivity<br /><br />IPv6 customer<br />IPv4+IPv6/MPLS core<br /><br /><br />Easy deployment:<br...
Content hosting<br />IPv6 core<br />?<br />?<br />?<br />Various levels of IPv6 support on:<br />Network-level firewalls<b...
Residential (consumer) Internet<br />?<br />?<br />?<br />IPv4+IPv6/MPLS core<br />?<br />?<br />?<br /><br />?<br />Comm...
Routing Table Explosion<br />Main caveats:<br />Careless/clueless Service Providers<br />Multihoming<br />Traffic engineer...
The biggest offenders<br />Source: CIDR report (Geoff Huston, www.cidr-report.org)<br />Potential “reasons”<br />Blind & s...
Traffic Engineering with BGP<br />Upstream ISP #1<br />Customer AS<br />½ PI<br />PI > /24<br />Upstream ISP #2<br />½ PI<...
Upcoming SlideShare
Loading in...5
×

Upcoming internet challenges

7,383

Published on

Today's Internet faces severe challenges including:

* IPv4 address exhaustion
* explosion of BGP tables and IP routing tables
* exponential traffic growth (which might not be a problem after all)

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,383
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Transcript of "Upcoming internet challenges"

  1. 1. Upcoming Internet challenges<br />Ivan Pepelnjak (ip@nil.com)NIL Data Communications<br />
  2. 2. The big three (from my perspective)<br />IPv4 address exhaustion<br />Routing table explosion<br />Traffic growth (or maybe not)<br />Business model failures<br />
  3. 3. IPv4 address exhaustion<br />Source: IPv4 address report (Geoff Huston, www.potaroo.net)<br />
  4. 4. IPv4 address exhaustion: solutions<br />Walled gardens<br />NAT444<br />DS-Lite/A+P<br />IPv6<br />
  5. 5. IPv4-only NAT options<br />CPE<br />CPE<br />Baseline:NAT44<br />RFC1918<br />IPv4 ProviderPrivate<br />IPv4 Internet<br />IPv4 Internet<br />IPv4 Internet<br />Walled garden<br />NAT44<br />IPv4 RFC1918<br />LSN<br />CGN/LSN<br />NAT444<br />RFC1918<br />LSN<br />
  6. 6. NAT options: DS-Lite or A+P<br />CPE<br />B4<br />DS-Lite<br />RFC1918<br />AFTR<br />IPv4 Internet<br />IPv4 Internet<br />IPv6<br />IPv6<br />A+P<br />RFC1918<br />AFTR<br />DS-Lite:<br />B4 is a smart bridge<br />AFTR does NAT44<br />A+P:<br />B4 is a NAT CPE<br />AFTR allocates IP address + port range to B4<br />
  7. 7. NAT-less IPv4 4ever<br />AFTR<br />IPv4 Internet<br />IPv6<br />A+P on the host<br />Native IPv6 for transport only<br />Tunnel from host to AFTR<br />~ 100x increase in address utilization<br />No need for public IPv6 deployment ... until we colonize the solar system<br />
  8. 8. Complexities of NAT<br />IPv6 does not require NAT<br /><ul><li>Public IPv6 addresses only
  9. 9. Simple P2P session setup
  10. 10. Both hosts must be IPv6-enabled</li></ul>198.51.100.22<br />198.51.100.22<br />10.0.0.2<br />10.0.0.2<br />10.0.0.2<br />10.0.0.2<br /><ul><li>NAT works well with client-server applications
  11. 11. Requests to server come from public IP address
  12. 12. Problem: protocols with embedded addresses (FTP, SIP)</li></ul>Network Address Translation (NAT)<br /><ul><li>Maps private IP addresses into public IP address space
  13. 13. Requires outbound session setup
  14. 14. P2P applications with NAT are a nightmare
  15. 15. End-to-end connectivity might not be possible
  16. 16. Fallback: public relay servers</li></li></ul><li>What is IPv6?<br />DNS<br />Web, Mail<br />DHCP<br />UDP<br />TCP<br />IPv4<br />ICMP<br />ARP<br />IPCP<br />DNS<br />Web, Mail<br />DHCPv6<br />UDP<br />TCP<br />ICMPv6<br />IPv6<br />IPCP<br /><ul><li>IPv6 is a replacement for IPv4
  17. 17. Longer addresses, new routing protocols, some other changes in L2/L3 protocols
  18. 18. Upper layers and applications should not change</li></li></ul><li>IPv6 adoption: the “ivory-tower” beliefs<br />Who caresabout IPv4?<br />IPv6 adoption [%]<br />IPv6 pilots<br />Time [years]<br />Ecstatic earlyadopters<br />Few years of dual-stack migration<br />IPv4 addressexhaustion<br />
  19. 19. IPv6 adoption: the unpleasant reality<br />IPv6 adoption [%]<br />IPv6-onlyclients?<br />NAT and RFC 1918<br />IPv6 pilots<br />Time [years]<br />Early adopters<br />15 yearswasted<br />IPv4 addressexhaustion<br />
  20. 20. Enterprise customer connectivity<br /><br />IPv6 customer<br />IPv4+IPv6/MPLS core<br /><br /><br />Easy deployment:<br />IPv6 edge is on the PE routers (no IPv6 support needed on access switches)<br />IPv6 over MPLS (6PE) or native IPv6 in the core<br />IPv6 over MPLS/VPN (6VPE) for L3 VPN services<br />Caveats:<br />Native IPv6 switching performance (PE routers or the whole core)<br />Packet filters<br />Keep IPv4 in the SP management plane<br />
  21. 21. Content hosting<br />IPv6 core<br />?<br />?<br />?<br />Various levels of IPv6 support on:<br />Network-level firewalls<br />Web application firewalls<br />Load balancers<br />Additional issues:<br />Coping with partial IPv6 connectivity<br />Application issues:<br />Legacy operating systems and web servers?<br />Incoming IPv6 session support?<br />IP address handling in logs and back-end databases?<br />
  22. 22. Residential (consumer) Internet<br />?<br />?<br />?<br />IPv4+IPv6/MPLS core<br />?<br />?<br />?<br /><br />?<br />Common issues:<br />IPv6 support in CPE equipment<br />IPv6 multicast support<br />IPv6 on 3play devices<br />IPv6-to-IPv4 translation<br />Consumer awareness<br />Legacy operating systems<br />Mobile networks<br />Only Nokia is IPv6-ready<br />DSL issues<br />IPv6CP support on CPE devices<br />Carrier Ethernet issues<br />DHCPv6 support on CPE devices<br />DHCPv6 and RA guard on the switches<br />
  23. 23. Routing Table Explosion<br />Main caveats:<br />Careless/clueless Service Providers<br />Multihoming<br />Traffic engineering<br />IPv4 address space fragmentation<br />Why is it bad?<br />CRS/GSR/7600 memory is expensive<br />High-end devices & TCAM not on Moore Law curve<br />BGP no longer reaches steady-state<br />
  24. 24. The biggest offenders<br />Source: CIDR report (Geoff Huston, www.cidr-report.org)<br />Potential “reasons”<br />Blind & stupid redistribution<br />Address space protection<br />Traffic engineering<br />
  25. 25. Traffic Engineering with BGP<br />Upstream ISP #1<br />Customer AS<br />½ PI<br />PI > /24<br />Upstream ISP #2<br />½ PI<br />
  26. 26. Multihoming<br />Upstream ISP #1<br />Customer AS<br />PI<br />PI prefix<br />Commercial reasons<br />Cheapest way to redundancy<br />Offload your costs to the community<br />No pollution tax<br />Technical reasons<br />Broken protocol stack<br />Broken socket API<br />IPv6 is not a solution(yet another urban legend)<br />Upstream ISP #2<br />PI<br />
  27. 27. Broken protocol stack<br />Application<br />Application<br />Application<br />DNS<br />Presentation<br />Session<br />Transport<br />Transport<br />TCP<br />UDP<br />Network<br />Internet<br />IPv4<br />IPv6<br />Data-link<br />Link layer<br />Other people’s problems<br />Physical<br />ISO/OSI<br />IETF <br />IETF implementation<br />Session layer is missing<br />Application sessions established between IP addresses<br />DNS is an optional add-on application<br />
  28. 28. Broken Socket API<br />conn = Network.Connect("example.com","http")<br />TBD<br />Ideal<br />conn = new Socket("example.com",80)<br />Java<br />OK<br />memset(&hints, 0, sizeof(hints));<br />hints.ai_family = PF_UNSPEC;<br />hints.ai_socktype = SOCK_STREAM;<br />error = getaddrinfo("example.com", "http", &hints, &res0);<br />if (error) { errx(1, "%s", gai_strerror(error)); }<br />s = -1;<br />for (res = res0; res; res = res->ai_next) {<br /> s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);<br /> if (s < 0) { cause = "socket"; continue; }<br /> if (connect(s, res->ai_addr, res->ai_addrlen) < 0) {<br /> cause = "connect";<br /> close(s);<br /> s = -1;<br /> continue;<br /> }<br /> break; /* okay we got one */<br />}<br />if (s < 0) { err(1, "%s", cause); }<br />Socket API<br />Broken<br />
  29. 29. Proposed fixes<br />SCTP<br />New transport protocol<br />Supports multihoming & streams<br />LISP<br />Global directory-driven mGRE/NHRP-like solution<br />shim6<br />Add-on for TCP over IPv6<br />HIP<br />Replaces IP address with signed host identifiers<br />Application<br />SCTP<br />HIP<br />TCP<br />UDP<br />shim6<br />IPv4<br />IPv6<br />LISP<br />Other people’s problems<br />IETF implementation<br />
  30. 30. IPv6 will make matters worse<br />IPv6 does not solve multihoming/TE issues<br />Even more PI prefixes than in IPv4<br />Each prefix requires 4x more memory<br />RS_AS6730>show ipbgp summary | include memory<br />327801 network entries using 33107901 bytes of memory<br />964287 path entries using 46285776 bytes of memory<br />98182 BGP path attribute entries using 5498864 bytes of memory<br />226 BGP rrinfo entries using 5424 bytes of memory<br />62132 BGP AS-PATH entries using 1583924 bytes of memory<br />52 BGP community entries using 1526 bytes of memory<br />203729 BGP route-map cache entries using 6519328 bytes of memory<br />0 BGP filter-list cache entries using 0 bytes of memory<br />BGP using 93002743 total bytes of memory<br />RS_AS6730>show proc mem | include Process|BGP<br /> PID TTY Allocated Freed Holding GetbufsRetbufs Process<br /> 119 0 4287871096 23691312 213522288 0 0 BGP Router<br /> 120 0 14954976 0 6856 0 0 BGP I/O<br /> 121 0 23432 1550080 32680 0 0 BGP Scanner<br />
  31. 31. Traffic explosion – is it a problem?<br />Facts<br />HDTV over access networks is a reality<br />Proven technology is available<br />It’s just a commercial question<br />Considerations<br />How much bandwidth do we really need?<br />What’s the killer application?<br />Source: monitoring of 20 Mbps residential Internet link Long-term average: 170 kbps<br />
  32. 32. More information<br />Webinars: http://www.ioshints.info<br />Market trends in Service Provider networks<br />Enterprise IPv6 deployment<br />Presentations: http://www.slideshare.net/ioshints<br />NAT64 and DNS64 in 30 minutes<br />Blog posts: http://blog.ioshints.info<br />Articles: Ivan Pepelnjak on SearchTelecom @ ioshints.info<br />

×