ipv4 address exhaustion and ipv6
play

IPv4 address exhaustion and IPv6 Glen Turner 2008-12-09 AARNet - PowerPoint PPT Presentation

IPv4 address exhaustion and IPv6 Glen Turner 2008-12-09 AARNet staff meeting aar net Australia's Academic and Research Network IPv6 policy Going forward, we seek to support IPv6 to the same extent as we support IPv4. Exceptions require


  1. IPv4 address exhaustion and IPv6 Glen Turner 2008-12-09 AARNet staff meeting aar net Australia's Academic and Research Network

  2. IPv6 policy Going forward, we seek to support IPv6 to the same extent as we support IPv4. Exceptions require the approval of the CEO. Rationale: Projects should make the extra effort to implement IPv6 now, at our own pace, rather than leave AARNet with a overhang of work to be done in 2010, at the pace of our most demanding customer.

  3. Where is AARNet? ● Native IPv6 service to our customers – Not-for-profit education and research, health, cultural institutions ● IPv6 broker – A best effort service to the greater community, especially developers ● Low deployment by customers – Didn't used to matter: by definition research has low initial usage – Slowly becoming a strategic issue, and we're trying various approaches to see what will fix that

  4. What next? ● Promote IPv6 to management ● Educate technologists ● Move IPv6 broker to a production service ● Move most of our public services to IPv6

  5. When will IPv4 be exhausted? See ipv4.potaroo.net

  6. When will IPv6 be deployed? ● No country has more than 1% of its hosts running IPv6 ● So, some considerable time after 2012 ● Conclusion: IPv6 ― the Plan A for IPv4 address exhaustion ― has already failed

  7. Why did IPv6 fail? ● Laying blame – Vendors: no product, they say no demand from ISPs – ISPs: no service, they saw no product and no demand from users – Users: no demand, bit hard to demand a non- existent service ● Lying vendors: “IPv6 support” isn't ● The emergence of ineffective lobbyists from ITU committees ● Government with severely burned fingers

  8. Why is IPv6 still failing? 36% Cost, time, business case 23% Vendor support, back-office 18% Knowledge, education 17% User demand 17% Upstream transit 14% Dual-stack interoperability 4% Multihoming 2% Allocation policy 2% Performance

  9. So what is Plan B? There is no Plan B

  10. Uh oh, so what is likely? B.1 Under utilised addresses will be sold B.2 ISPs will run network address translation B.3 Some ISPs will offer IPv6

  11. Internet in 2012 aar net Australia's Academic and Research Network

  12. Typical ISP's customer ● Carrier-class NAT for IPv4 – Potential for services lock in and other “walled garden' anti-competitive practices ● IPv6 with global addressing available from enlightened ISPs – Allowing the customer to escape any walled garden

  13. Typical AARNet customer ● AARNet has a small number of large customers ● So we can provide one IPv4 address per customer – Use that address for globally-accessible services – And use that address to NAT traffic into their network – No need to ask AARNet for support of peculiar protocols: the NAT module is the customer's concern

  14. B1. Market for IPv4 addresses aar net Australia's Academic and Research Network

  15. Who owns addresses? ● In the beginning they were allocated to sites – Unsustainable routing table growth, as one entry per site in core routers – “Portable” between ISPs ● Regional Internet registries allocate to ISPs, who allocate to customers' sites – One entry per ISP in core routers – “Non-portable” between ISPs

  16. Checking address allocation $ whois 129.127.0.0/16 inetnum: 129.127.0.0 - 129.127.255.255 netname: ADELAIDE descr: University of Adelaide country: AU admin-c: LC457-AP tech-c: LC457-AP tech-c: SB248-AP status: ALLOCATED PORTABLE remarks: This object was transferred from ARIN database remarks: on 11 December 2002 mnt-by: APNIC-HM changed: hm-changed@apnic.net 20021211 changed: hm-changed@apnic.net 20040926 changed: hm-changed@apnic.net 20041214 source: APNIC

  17. mnt-by and portable addresses ● Who can make changes? ● The people in the mnt-by field ● A lot of our members have insecure records

  18. Contracts and non-portable ● Non-portable addresses do not belong to the site ● But site's have a significant investment in their allocated addressing ● The ISP could remove this allocation and assign it to another use – No need for the ISP to do this – Until they run out of addresses themselves ● Future contracts with ISPs need to spell out addressing more specifically

  19. Trading addresses ● When originally allocated, the regional routing registries explicitly said that IP addresses would not be tradeable ● They're changing their mind, and the routing registries will eventually act as a registry for address ownership rather than address allocation ● Addresses will be worth money – Some of our customers will sell – We may need to buy addresses – Our contracts need to be more explicit on this issue

  20. B2. Network address translation Technology aar net Australia's Academic and Research Network

  21. How does NAT work? ● Inspect outgoing traffic – Collect ( src_addr , src_port , dst_addr , dst_port ) ● Re-write src_addr to my exterior interface, find an unused source port on my exterior interface and re-write src_port to that ● Record these addresses and ports in the expectation table (150.101.30.33, 20000, (10.1.1.1, 10000, 202.158.201.38, 80) 202.158.201.38, 80) (150.101.30.33, 20000, 10.1.1.1, 10000, 202.158.201.38, 80)

  22. How does NAT work? ● Inspect incoming traffic ● Is the incoming ( src_addr , src_port , dst_addr , dst_port ) in the expectation table? ● Re-write the dst_addr and dst_port to the original values in the table (202.158.201.33, 80 (202.158.201.38, 80 150.101.30.33, 20000) 10.1.1.1, 10000) (150.101.30.33, 20000, 10.1.1.1, 10000, 202.158.201.38, 80)

  23. Wrinkles with NAT ● Some protocols embed IPv4 addresses – These need to be rewritten too – May be complex (and thus dangerous) to do in the forwarding plane ● eg: SNMP uses ASN.1 encoding ● Some protocols embed forthcoming connection information ● FTP, Cisco Skinny, a lot of multimedia – These wrinkles are handled by “NAT modules” ● inspect the traffic, add entries to the expectation table ● Result: non-standard protocols have poor NAT support

  24. Benefits of NAT ● Has lead to the widespread deployment of stateful, deep packet inspection firewalls – Although coding inspection for NAT and firewall can require choices, so NAT is not the best choice of DPI firewall ● Which is why defence runs real addresses ● NAT requires DPI, DPI doesn't require NAT ● Reduced the rate of IPv4 address exhaustion, delaying the crisis until now

  25. Problems with NAT ● Complex – Forwarding plane moves from ASIC to CPU ● Jitter and complexity attacks – Some packets need a lot more work than others ● Exploits of code with errors – Complex code, so errors certain ● Huge amounts of state – Abundant opportunity for resource exhaustion ● Timeouts – Some traffic simply isn't suitable: low-power devices, sensors, episodic multimedia

  26. Implications ● The edge of the customer is no longer globally reachable – as it is no longer a globally-unique address ● The customer cannot run web servers, e-mail, etc

  27. Implications ● So to continue as things are, ISPs will need to allocate an increasingly-scarce IPv4 address to the customer's network edge ● The ISP will charge for this – Since the ISP themselves will need to pay for addresses ● The worst-case figure I've seen from an educated industry participant is $1,000pa – But no one really knows

  28. Security implications ● Globally-reachable IPv4 addresses will become increasing scarce ● But in demand by the “finding each other” applications ● Our customers have a lot of these addresses ● Our customers become a hot spot of network abuse ● ISPs don't run intrusion detection, opportunity for AARNet here

  29. Design implications ● Increased complexity and storage of NAT is exploitable – A less robust Internet ● Latency will increase – These will be expensive boxes, so there will be only a few in a ISP's network – Gamers will love IPv6 ● There is no end-to-end visibility

  30. No end-to-end visibility ● We're sort of used to that: sharing photos on Flickr rather than on a home router ● Real IPv4 addresses are already special – Skype supernode – Who wants to volunteer to run a real IPv4 address in a NAT world? ● Some applications work better when all participants are reachable – peer-to-peer protocols – large videoconferencing

  31. The “walled garden” ● Telcos maximise profits by charging users the value of the service, not the cost of provision – This is why ISD phone calls used to be charged for at outrageous rates, even though costs are <$0.01/ min – It's why telcos try to do exclusive content deals ● In interests of other vendors to team with the telco rather than with the customer ● The customer-built Internet broke this – Telco customers built it, so their interests ruled – Telcos reduced to being low-rent packet shifters

  32. The return of the walled garden? ● Potential for Evil ISPs to move the Internet from a low-rent transport to a walled garden where the only services available are those selected by the ISP ● eg: – SIP is the protocol used for phone calls – Let's not run the NAT module for SIP and friends – Customers will need to use our voice service – No other voice service can be easily accessed (and doing so is arguably “hacking”) – Evil ISP charges VoIP packets at higher rate than other packets

Recommend


More recommend