Overview
• No more IPv4!• Possible solutions• RFC 5549
2RIPE 65 Amsterdam 25-09-2012
No more IPv4!
• AMS-IX Internet peering VLAN:• 1024 IPv4 (/22)•
18,446,744,073,709,551,616 IPv6 (/64)
3RIPE 65 Amsterdam 25-09-2012
No more IPv4!
IPv4 usage 2006-2012Latest data: 11-sept-2012
– Used: 657
– Left: 367
4RIPE 65 Amsterdam 25-09-2012
01-01-2006 01-01-2008 01-01-2010 01-01-20120
100
200
300
400
500
600
700
800
Used IPv4
Left IPv4
No more IPv4!
Growth of IPv4 usageLatest data: 11-sept-2012
• 56, but we still have 4 months to go..
Probable reason: AMS-IX reseller program
5RIPE 65 Amsterdam 25-09-2012
2006 2007 2008 2009 2010 2011 20120
10
20
30
40
50
60
70
80
90
Predicted
Growth
No more IPv4!
Predicted growth of IPv4 usage– Worst case: 100 each year, depletion 2016
– Best case: 75 each year, depletion in 2017
6RIPE 65 Amsterdam 25-09-2012
01-01-2006 01-01-2008 01-01-2010 01-01-2012 01-01-2014 01-01-2016 01-01-20180
200
400
600
800
1000
1200
1400
Recorded IPv4 usage
Predicted IPv4 usage 100
Predicted IPv4 usage 75
1024
Overview
• No more IPv4!• Possible solutions• RFC 5549
7RIPE 65 Amsterdam 25-09-2012
Possible solutions
#1: Bigger subnet (/21)
● Because IPv4 address space is unlimited!... Oh wait...● Could give us +-10 more years● Bigger IPv4 broadcast domain == more ARP problems● Not a solution, just a workaround
8RIPE 65 Amsterdam 25-09-2012
Possible solutions
#2: Private address space● No member (500+) could use that private range anymore● Including management interfaces● ACLs deny private range traffic
9RIPE 65 Amsterdam 25-09-2012
Possible solutions
#3: Advertising IPv4 next-hopsCould we use an IPv6 address as a next hop for its IPv4 routes?
10RIPE 65 Amsterdam 25-09-2012
Possible solutions
#3.1: 4in6 tunnel ● With what IPv4 addresses as termination points?● Wouldn't solve our problem
11RIPE 65 Amsterdam 25-09-2012
Possible solutions
#3.2: '4in6' Softwire mesh tunnel [RFC 5565]●Tunnel terminates in the router itself●Encapsulate every IPv4 packet (+40B per packet)●Non-IPv4 members can participate in IPv4 routing
12RIPE 65 Amsterdam 25-09-2012
Possible solutions
#3.3: Just send out the IPv4 packet●We actually only need a L2 address for the next hop●No need for encapsulation == no overhead●But what if the next hop is not dual stack?
13RIPE 65 Amsterdam 25-09-2012
RFC 5549
14RIPE 65 Amsterdam 25-09-2012
• No more IPv4!• Possible solutions• RFC 5549
RFC 5549
15RIPE 65 Amsterdam 25-09-2012
RFC 5549
*Receive an MP_BGP update message**Look at the MP_REACH_NLRI attribute*
IF ((Update AFI == IPv4)
&&
(Length of next hop == 16 Bytes || 32 Bytes))
{
This is an IPv4 route with an IPv6 next hop;
}
16RIPE 65 Amsterdam 25-09-2012
RFC 5549
Example MP_REACH_NLRI attribute:●AFI: = 1 (IPv4)●SAFI: = 1 (unicast)●Next hop length = 32●Next hop address = 2001::2 & FE80::1●NLRI = 192.0.2.0/24
17RIPE 65 Amsterdam 25-09-2012
RFC 5549
18RIPE 65 Amsterdam 25-09-2012
RFC 5549
BGP capability advertisementUsed to signal BGP capabilities between peers in OPEN message
Capability code: 5 Extended Next Hop Encoding
NLRI AFI: 1 IPv4
NLRI SAFI: 1 Unicast
Nexthop AFI: 2 IPv6
19RIPE 65 Amsterdam 25-09-2012
RFC 5549
20RIPE 65 Amsterdam 25-09-2012
RFC 5549
Possible NLRI AFI/SAFI combinationsAFI= IPv4 (1)
SAFI● Unicast (1)● Multicast (2)● Include an MPLS Label (4)● MPLS-labeled VPN address (128)
Next hop = IPv6
21RIPE 65 Amsterdam 25-09-2012
RFC 5549
Pros:●IXPs wouldn't need IPv4 anymore●No more ARP flooding
Cons:●Forwarding might be complicated●No real implementations yet (as fas as we know)●Members need to implement this, not AMS-IX
22RIPE 65 Amsterdam 25-09-2012
Questions/comments/brilliant solutions:[email protected]