[rpd] A typical conversation with a service provider on v6

[Mark Tinka]

On Monday, June 16, 2014 05:34:41 PM Seun Ojedeji wrote:

> I am sure anyone would agree with this, the reality
> however is that the margin for now is quite wide and
> ISPs who are meant to reduce the distance to getting to
> such promise land (where v6 networks is > v4) are not
> moving.

Indeed, and what I keep alluding to is that market forces 
will deal with that gap. Either those ISP's will get the 
fire on their behinds to close the gap, or the market will 
force them out of business.

> And that is my point; end users are ready to receive v4
> or v6 (just like facebook servers nodes are ready) and
> so they don't have anything to worry about.

Not quite.

A number of mobile phone OS's have various IPv6 issues
that still need addressing (no pun intended).

But that is beside the point...

> Those who
> need to worry (and who are actually not) are the
> "network service providers". What we find now is that
> end-users are the ones trying to move the ISP which
> should actually be the other way round.

I don't know of markets where basic Internet users are
driving demand for IPv6 (power users, like you and I,
of course), because they just don't care.

> On a lighter
> note, i also don't see facebook going native v6 soon
> because no content provider wants to take the frog jump
> especially when he knows that the landing ground is not
> as soft with v6 users ;)

[tinka at nms ~]$ traceroute6 -I www.facebook.com
traceroute6 to star.c10r.facebook.com (2a03:2880:f00a:501:face:b00c:0:1) from 2c0f:feb0:9:1::2, 64 hops max, 16 byte packets
 1  ge-0-1-0-210.jnb6-201-access-1.mpls.seacomnet.com  0.464 ms  0.246 ms  0.202 ms
 2  xe-9-0-0.jnb6-201-access-3.mpls.seacomnet.com  0.497 ms  0.236 ms  0.210 ms
 3  xe-10-0-0.mtz6-201-access-3.mpls.seacomnet.com  10.637 ms  10.539 ms  10.515 ms
 4  xe-11-0-0.mba6-201-access-1.mpls.seacomnet.com  47.353 ms  47.181 ms  47.129 ms
 5  xe-0-1-0.mba6-201-access-3.mpls.seacomnet.com  47.437 ms  47.345 ms  47.179 ms
 6  xe-3-0-0.lon6-201-access-3.mpls.seacomnet.com  1541.589 ms  2892.580 ms  714.738 ms
 7  xe-0-0-1-0.pp6-01-lhr.uk.seacomnet.com  177.241 ms  177.187 ms  177.186 ms
 8  2001:7f8:4::80a6:1  177.496 ms  177.492 ms  177.500 ms
 9  ae1.bb01.lhr2.tfbnw.net  177.650 ms  177.539 ms  177.528 ms
10  ae0.pr02.lhr2.tfbnw.net  177.703 ms  177.714 ms  178.663 ms
11  po126.msw01.06.lhr2.tfbnw.net  177.958 ms  177.965 ms  177.964 ms
12  edge-star6-shv-06-lhr2.facebook.com  177.452 ms  177.469 ms  177.456 ms
[tinka at nms ~]$

Facebook's main web site has been dual-stacked for a 
while now. They aren't the only ones.

> > Mmm....i think it does, so can you at Seacom decide as
> > a matter of policy
> not to peer with provider that does not also provide v6?

No, we can't, because we are a profit-making organization,
like the majority of ISP's around the world. We are here to 
serve our customers, and not use them as examples.

A peer's inability to support IPv6 is not my problem. It
is theirs. And as I do not know the inner workings of their
organization, who am I to judge?

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140616/13cd206b/attachment.sig>