Cogent - Google - HE Fun

Matthew D. Hardeman mhardeman at ipifony.com
Thu Mar 10 22:53:31 UTC 2016


Mark,

I certainly agree that intentional harm of a purely malicious nature is to be discouraged.

What I proposed, as an alternative to some of the more extreme mechanisms being discussed, is a mechanism whereby IPv6 _customers_ of Cogent transit services--and who also receive IPv6 transit from at least one other relationship--can modify their IPv6 advertisements to Cogent such that they utilize that transit link with Cogent for the one thing you can reliably count on it for in the IPv6 world: reaching other Cogent IPv6 customers, especially the single-homed ones.

In essence, adding BGP community “174:3000” to your IPv6 advertisements to Cogent instructs Cogent that this route should only be advertised internal to Cogent and to Cogent’s customers.  It should not be announced to peers.  Combining that with prepends of your own AS in the IPv6 advertisements to Cogent also reduces traffic from other multi-homed Cogent IPv6 customers.  In any event, if enough Cogent customers do this, it does greatly reduce the amount of traffic that Cogent gets to transit from their various IPv6 peers while still avoiding harm to innocent end-users (or for that matter, to guilty end users).

The mechanism I proposed has numerous benefits:

1.  It utilizes only a mechanism created by Cogent and documented for use by Cogent transit customers to achieve routing policy that benefits IPv6 customers of Cogent.
2.  It causes no harm to single-homed Cogent customers.
3.  It causes no direct harm to Cogent.  The sole indirect harm that it might bring upon Cogent if adopted en-masse would be to significantly drop the amount of traffic crossing Cogent’s SFI peerings on IPv6, which I acknowledge may have consequences for Cogent.  If it did have such consequences, it’s Cogent’s game and Cogent’s rules.  They could change it any time.  If it indirectly harms Cogent by lowering overall traffic volume on paid multi-homed customer transit connections, Cogent could easily remedy that by becoming an IPv6 network that one would want to exchange IPv6 transit traffic with rather than being an IPv6 network that one begrudgingly pays because one does business with others who are Cogent single-homed.

I do reiterate, however, that I would strongly discourage any kind of routing tricks that leave the innocent Cogent customers out in the cold.  That hurts those Cogent customers as well as you and/or your own customers and users.  Please, someone, think of the end-users here.

My advice to Cogent would be to remember something real simple:  When Big Boss #1 at RandomCorp has no trouble reaching Google services all night every night at home and then he comes to work and his office Internet does everything but Google….  What he’ll remember is “Charter works with Google, whoever we’re using at the office doesn’t.  Let’s switch.”  It’s shocking to me that an ISP with a retail segment thinks you can survive if Google doesn’t work, no matter what Google did to ensure it played out that way.  Frankly, Google could scream that they cut Cogent off because they didn’t like Cogent’s face and no one at retail would care.  They just want their Gmail back.  If Google wanted to force the issue faster, they could just stop the IPv4 transit routes to Cogent.  I think they’re taking a more balanced and conservative approach though.

Thanks,

Matt Hardeman

> On Mar 10, 2016, at 4:29 PM, Mark Andrews <marka at isc.org> wrote:
> 
> 
> I don't think anyone should be colluding to hurt Cogent or anyone
> else for that matter and this thread appears to be heading in this
> direction.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4190 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160310/0d769164/attachment.bin>


More information about the NANOG mailing list