Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Summary of proposals: IPv4 Runout Management

Kevin Kamonye kevin.kamonye at gmail.com
Fri Nov 11 11:27:37 UTC 2016


And I will sign out of this thread with the below.

IP was originally created for end-to-end connectivity, but we’ve gotten
away from that as Internet growth has taken off and added many technologies
to help *slow the consumption of IPv4*. With IPv6, we’re able to return to
end-to-end connectivity, and who knows what new technologies can then be
created, with address shortages now a thing of the past?

It’s time to make the transition to IPv6. Don’t be left behind!

*https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/*
<https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/>

*Kevin*


On 11 November 2016 at 14:05, Kevin Kamonye <kevin.kamonye at gmail.com> wrote:

> That is a good read Owen (including the contents of your mails, for
> sure!). Such needs wide circulation and prominence.
>
> They even seem to be having fun with it while we hang on to I just don't
> know what..
>
> IPv6 addresses aren't really supposed to spell out domain names, but
> Facebook has adopted an IPv6 addy that includes the characters "faceb00c."
>
> A quick DNS lookup of facebook.com confirms this: the domain resolves to
> 2a03:2880:2130:cf05:face:b00c::1. Faceb00c. Get it?
>
> At The Reg's London office, we can’t agree on what we should think about
> that.
>
> IPv6.BBC.co.uk also resolves to 2001:4b10:bbc::1 and 2001:4b10:bbc::2, so
> maybe this is a thing now? What do you reckon?
>
> *http://www.theregister.co.uk/2015/07/08/facebook_casts_a_hex_on_dns/
> <http://www.theregister.co.uk/2015/07/08/facebook_casts_a_hex_on_dns/>*
>
> Well done to the team @ .*face:b00c.*
>
> And its not all just fun and games..
>
> Facebook News Feeds Load 20-40% Faster Over IPv6
> <http://www.internetsociety.org/deploy360/blog/2015/04/facebook-news-feeds-load-20-40-faster-over-ipv6/>
>
> Kevin
>
> On 10 November 2016 at 23:05, Owen DeLong <owen at delong.com> wrote:
>
>> On Nov 9, 2016, at 23:14 , Noah <noah at neo.co.tz> wrote:
>>
>> If people want to deploy IPv6 they will do it but the compeling reason
>> will eventually be competition as the motivation and nothing else.
>>
>> Atleast folk i know who do it dont even dual stack in their core as the
>> prefix basically just seats on their boader router facing their ISP for the
>> purpose of announcing it and that is it.
>>
>> Really?
>>
>> You don’t know very many people then… Here are some I know:
>>
>> Pinging www.facebook.com:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2a03:2880:f127:83:face:b00c::25de
>> 16 bytes from 2a03:2880:f127:83:face:b00c::25de, icmp_seq=0 hlim=53
>> time=78.875 ms
>> 16 bytes from 2a03:2880:f127:83:face:b00c::25de, icmp_seq=1 hlim=53
>> time=76.036 ms
>> 16 bytes from 2a03:2880:f127:83:face:b00c::25de, icmp_seq=2 hlim=53
>> time=75.961 ms
>>
>> --- star-mini.c10r.facebook.com ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 75.961/76.957/78.875/1.356 ms
>> 0.001u 0.003s 0:02.13 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.google.com:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2607:f8b0:4005:801::2004
>> 16 bytes from 2607:f8b0:4005:801::2004, icmp_seq=0 hlim=55 time=31.035 ms
>> 16 bytes from 2607:f8b0:4005:801::2004, icmp_seq=1 hlim=55 time=31.229 ms
>> 16 bytes from 2607:f8b0:4005:801::2004, icmp_seq=2 hlim=55 time=30.146 ms
>>
>> --- www.google.com ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 30.146/30.803/31.229/0.472 ms
>> 0.000u 0.002s 0:02.03 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.comcast.net:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2600:1406:34::b819:388d
>> 16 bytes from 2600:1406:34::b819:388d, icmp_seq=0 hlim=56 time=35.388 ms
>> 16 bytes from 2600:1406:34::b819:388d, icmp_seq=1 hlim=56 time=35.445 ms
>> 16 bytes from 2600:1406:34::b819:388d, icmp_seq=2 hlim=56 time=30.565 ms
>>
>> --- a1526.dscg.akamai.net ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 30.565/33.799/35.445/2.287 ms
>> 0.000u 0.002s 0:02.05 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.netflix.com:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2620:108:700f::36ba:99e4
>> 16 bytes from 2620:108:700f::36ba:99e4, icmp_seq=0 hlim=43 time=50.512 ms
>> 16 bytes from 2620:108:700f::36ba:99e4, icmp_seq=1 hlim=43 time=50.382 ms
>> 16 bytes from 2620:108:700f::36ba:99e4, icmp_seq=2 hlim=43 time=50.202 ms
>>
>> --- www.latency.prodaa.netflix.com ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 50.202/50.365/50.512/0.127 ms
>> 0.000u 0.004s 0:02.07 0.0% 0+0k 0+0io 0pf+0w
>> Pinging whitehouse.gov:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2001:428:6402:19c::2add
>> 16 bytes from 2001:428:6402:19c::2add, icmp_seq=0 hlim=56 time=48.869 ms
>> 16 bytes from 2001:428:6402:19c::2add, icmp_seq=1 hlim=56 time=49.243 ms
>> 16 bytes from 2001:428:6402:19c::2add, icmp_seq=2 hlim=56 time=48.470 ms
>>
>> --- whitehouse.gov ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 48.470/48.861/49.243/0.316 ms
>> 0.000u 0.002s 0:02.09 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.irs.gov:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2600:1406:40:2bb::f50
>> 16 bytes from 2600:1406:40:2bb::f50, icmp_seq=0 hlim=55 time=35.796 ms
>> 16 bytes from 2600:1406:40:2bb::f50, icmp_seq=1 hlim=55 time=30.659 ms
>> 16 bytes from 2600:1406:40:2bb::f50, icmp_seq=2 hlim=55 time=30.862 ms
>>
>> --- e3920.dscna.akamaiedge.net ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 30.659/32.439/35.796/2.375 ms
>> 0.000u 0.003s 0:02.05 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.usda.gov:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2600:1406:1a:39a::500
>> 16 bytes from 2600:1406:1a:39a::500, icmp_seq=0 hlim=56 time=149.769 ms
>> 16 bytes from 2600:1406:1a:39a::500, icmp_seq=1 hlim=56 time=147.715 ms
>> 16 bytes from 2600:1406:1a:39a::500, icmp_seq=2 hlim=56 time=145.721 ms
>>
>> --- e1280.dscb.akamaiedge.net ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 145.721/147.735/149.769/1.653 ms
>> 0.000u 0.004s 0:02.17 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.juniper.net:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2600:1406:1a:3a0::720
>> 16 bytes from 2600:1406:1a:3a0::720, icmp_seq=0 hlim=56 time=148.142 ms
>> 16 bytes from 2600:1406:1a:3a0::720, icmp_seq=1 hlim=56 time=150.608 ms
>> 16 bytes from 2600:1406:1a:3a0::720, icmp_seq=2 hlim=56 time=145.517 ms
>>
>> --- e1824.dscb.akamaiedge.net ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 145.517/148.089/150.608/2.079 ms
>> 0.000u 0.002s 0:02.17 0.0% 0+0k 0+0io 0pf+0w
>> Pinging www.cisco.com:
>> PING6(56=40+8+8 bytes) 2620::930:0:380a:e409:25b4:1014 -->
>> 2600:1406:1a:389::90
>> 16 bytes from 2600:1406:1a:389::90, icmp_seq=0 hlim=56 time=145.665 ms
>> 16 bytes from 2600:1406:1a:389::90, icmp_seq=1 hlim=56 time=145.943 ms
>> 16 bytes from 2600:1406:1a:389::90, icmp_seq=2 hlim=56 time=145.636 ms
>>
>> --- e144.dscb.akamaiedge.net ping6 statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/std-dev = 145.636/145.748/145.943/0.138 ms
>> 0.000u 0.002s 0:02.17 0.0% 0+0k 0+0io 0pf+0w
>>
>> I know more, but I think that gets the point across.
>>
>> So announcing an IPv6 prefix to an upstream provider imho doesnt cut it
>> and its easy to do.
>>
>>
>> That’s true… Really deploying IPv6 is what is needed and it is happening
>> with or without the African region.
>>
>> Guess what happens in the rest of the world shortly after IPv6 is
>> sufficiently deployed that IPv4 stragglers are no longer considered
>> sufficiently relevant to justify the costs?
>>
>> Don’t believe me… Read this:
>>
>> ​​
>> http://www.internetsociety.org/deploy360/resources/case-stud
>> y-facebook-moving-to-an-ipv6-only-internal-network/
>>
>> This is from 2014… They’ve continued to progress down the turn off IPv4
>> internally road since then.
>>
>> AWS and Microsoft Azure have now deployed IPv6 support for their cloud
>> platforms.
>>
>> Amazon’s ROUTE53 DNS service now has IPv6 support.
>>
>> If you truly want to see the African region able to meaningfully interact
>> with the internet going forward, focusing on IPv4 will not serve you well.
>>
>> Owen
>>
>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161111/48d92f22/attachment-0001.html>


More information about the RPD mailing list