RCN (AS6079) Peering and Interconnects

Last updated: 11 JAN 2018

 Technical and Procedural Policy in Summary
 All peers must have NOCs with Internet email addresses, voice
 telephone numbers, and 24x7 coverage. All peers are expected
 to communicate contact updates in a timely manner. All peers
 are expected to proactively send updates regarding maintenance
 activities, outages, and other significant activities. All
 peers will be notified likewise by RCN.
 All peers must agree to actively cooperate in resolving at
 least the items in the following non-exhaustive list:
 - security violations
 - denial of service attacks
 - network abuse (including but not limited to spam issues)
 - downed peering sessions, interfaces, or circuits
 - disrupted, damaged, or flapping peering sessions
 - similar/related infrastructure and security issues
 All peers must not abuse the peering relationship by doing any
 of the following non-exhaustive list:
 - pointing default
 - resetting next hop
 - selling, bartering, trading or giving either routes or next
 hop to third parties (non-customers)
 - leaking routes to third parties (non-customers)
 - sending inconsistent prefixes (in number, origin, or other
 attributes) without prior agreement
 All peers are requested to enable LSRR on router interfaces
 facing RCN peering sessions to facilitate network diagnostics
 at least during session activation. 
 All peers will be configured for closest-exit routing unless
 otherwise expressly agreed. All peers are expected to offer
 consistant routes to facilitate closest-exit routing unless
 otherwise expressly agreed. This consistancy is expected
 in next-hop, origin, MED, and all other such decision-making
 attributes; non-conforming routes can be rewritten at the
 discretion of RCN. Agreements for best-exist or other forms
 of traffic exchange can be made in email.
 All peers are expected to utilize IRR resources. All peers
 will be configured with loose prefix limits based upon
 registered/announced routes to guard against leaks. Peers
 are encouraged to register routes or send notice in advance
 of dramatic deltas in announcements to allow for adjustments
 to those limits.
 Potential peers must be present in more than one common peering
 location; RCN will not activate single-region peers. Potential
 peers must be willing to enter into agreements with RCN, though
 no execution of agreements is presently required for public
 peering. Private peering with RCN requires the execution of
 a Bilateral Peering Agreement (BLPA). The transmission of a
 BLPA requires a non-disclosure agreement (NDA) be in place
 between the respective parties. All discussions regarding
 private peering are under NDA.
 RCN reserves the right to peer or not with any network as we
 see fit, for any reason, without requirement of disclosure.
 RCN will not peer with any network that has been an IP transit
 customer within the past nine (9) months. RCN reserves the
 right to terminate public peering at any time with 30 days'
 notice. Such advance notice is neither guaranteed nor
 required for unresponsive, abusive, or negligent peers.
 RCN reserves the right to change this peering policy without

 Contact and IRR Information
 Adminstrative/Technical Contact (peering agreements, engineering)
 Name: Peter D. Jacoby
 Phone: +1.781.316.8815
 FAX: +1.320.341.2904
 E-mail: peering@rcn.com
 NOC (troubles & notices)
 Phone: +1.888.972.6622
 E-mail: noc-peering@rcn.com
 ASN: 6079
 Aut-num: AS6079

NAP IPv4 address IPv6 address VPI/VCI DLCI Status Mcast? Notes
NOX up yes
Equinix NY (was PAIX-NY) 2001:504:F::17 up no
Equinix Ashburn 2001:504:0:2::6079:1 up no
NYIIX 2001:504:1::A500:6079:1 up by request
Equinix Chicago (old) (new)
2001:504:0:4::6079:1 up no
Boston Internet Exchange 2001:504:24:1::17BF:1 up no
DE-CIX-NY 2001:504:36::17bf:0:1 up no
"Mcast" indicates multicast-enabled peering location