Support Center

BGP IPv4 peer filter policy

The following is the NTT filtering policy with its peers:

Inbound

• NTT accepts only those prefixes of length /24 and shorter from traditional class A, B, and C space.
• NTT uses max-prefix filters at most public exchanges. The max-prefix filter is set to 110% of the greater of the following values:
  • number of prefixes announced in the last 24 hours
  • number of prefixes registered in the routing registries under the peer’s as-set if this number is less than 5000.

Outbound

• NTT will accept any properly registered prefix from our customers but will announce only /24 and shorter prefixes to our peers.
• All NTT announcements are registered in one of the routing registries and included under as-set AS2914:AS-GLOBAL.

NTT reserves the right to modify this policy without prior notice.

BGP IPv6 peer filter policy

The Internet community filters IPV6 announcements based on the IPV6 allocations from ARIN. The allocations (and filtering) are necessary in order to minimize routing table expansion. Any customer requiring BGP multi-homing, now or in the future, should apply for Provider Independent (PI) IPv6 space directly from ARIN. ARIN can also allocate /48 critical infrastructure space if justified (eg. root domain operators). Customers with multiple connections to the NTT network may announce longer prefixes along with their ARIN allocation to effectively manage their inbound traffic, but longer prefixes than /48 will not be propagated beyond the AS2914 backbone.

More information regarding ARIN’s IPv6 assignment and allocation policies can be found here: http://www.arin.net/policy/nrpm.html#six

The following is the NTT filtering policy with its peers:

Inbound

• NTT will accept /48 and shorter prefixes from our peers.

Outbound

• NTT will announce /48 and shorter prefixes to our peers.

NTT reserves the right to modify this policy without prior notice.

Global IP Network Routing Registry

Attn: NTT GIN utilizes RPKI-aware mode on its Internet Routing Registry service (rr.ntt.net) and will suppress route(6) IRR records that conflict with published RPKI ROAs.

More information on this functionality can be found at the IRRd RPKI integration documentation.

The Global IP Network requires all customers using BGP to register each route that will be advertised in either:

1. the Global IP Network routing registry, or
2. one of the Internet routing registries mirrored by in the Global IP Network routing registry
3. the NIC.br public whois registry at registro.br
4. the global RPKI using an RPKI ROA

The current list of mirrored registries is:

• AFRINIC
• ALTDB
• APNIC
• ARIN
• BBOI
• BELL
• CANARIE
• IDNIC
• JPIRR
• LACNIC
• LEVEL3
• RADB
• REGISTROBR
• RIPE
• RIPE-NONAUTH
• RPKI
• TC

Global IP Network customers are welcome to register their routes in the Global IP Network routing registry. For more specific information, please see visit our Routing Registry page.

Note: Please make sure all of your Route Objects (ROs) are registered under your ASN or AS-SET. In addition, we do not recommend relying on proxy ROs. Just as they are automatically created, they can be automatically deleted.

Route Dampening

The Global IP Network does not use route dampening.

BCP 214 / RFC 8327 BGP Session Culling Compliance

The Global IP Network is compliant with BCP 214 / RFC 8327, specifically section 3.1 “Voluntary BGP Session Teardown Recommendations”.

Before NTT GIN commences activities that can cause disruption to flow of data through Internet circuits, NTT GIN will – whenever possible – reduce loss of traffic by issuing an administrative shutdown to all BGP sessions running across the circuit and wait a few minutes for data-plane traffic to subside.

While architectures exist to facilitate quick network reconvergence (such as BGP Prefix Independent Convergence (BGP PIC), NTT GIN cannot assume the remote side has such capabilities. As such, a grace period between the Administrative Shutdown and the impacting maintenance activities is warranted.

After the maintenance activities have concluded, NTT will restore the BGP sessions to their original Administrative state.

Bogon ASN Filter Policy

The Global IP Network will not accept route announcements from any eBGP neighbors which contain a Bogon ASN anywhere in the AS_PATH or its atomic aggregate attribute. Bogon ASNs are defined as 0, 23456, 64496 through 131071 and 4200000000 through 4294967295.

NTT GIN BGP-4 NEXT_HOP Policy

The Global IP Network deviates slightly from the RFC 4271 BGP-4 specification, specifically section 6.3 “UPDATE Message Error Handling”, regarding the contents of the BGP NEXT_HOP attribute.

The NTT GIN network has stricter requirements for IP addresses in the BGP NEXT_HOP attribute than RFC 4271 mandates. RFC 4271 allows any IP address that is part of a common subnet between the sending and receiving BGP speaker as a semantically correct NEXT_HOP. However, NTT GIN strictly requires the advertised BGP NEXT_HOP be the sender’s IP address that is used to establish the EBGP connection.

MEDs

The Global IP Network accepts MEDs from its customers.

Graceful BGP Session Shutdown

To reduce the amount of traffic lost when BGP sessions are about to be shut down deliberately, e.g., for planned maintenance, the Global IP Network supports receiving and honoring the Graceful Shutdown BGP community 65535:0 (also known as “GRACEFUL_SHUTDOWN”) on all EBGP sessions.

More information about Graceful BGP Session Shutdown is available in RFC 8326.

Blackhole and Selective Blackhole service

Customers may announce hosts tagged with 2914:666 for v4 and v6 peering. Any /32 or /128 host tagged with this community will be discarded as soon as it reaches our network. The /32 or /128 prefix must be one included in the customer’s existing ingress BGP filter. By default, peers are not configured for the blackhole functionality. Please contact the NTT NOC @ noc@gin.ntt.net for this feature.

As of the beginning of March, 2015, NTT now offers Selective Blackholing. This provides the ability to limit the scope of the blackholing to certain geographic locations, allowing a more strategic application of the blackhole service.

Policy for prefix origination from GIN equipment and ASNs

Parties seeking to announce prefixes originating from GIN-operated equipment or originating from a GIN-operated ASN will be required to publish and maintain a valid RPKI ROA with an origin of the relevant ASN (typically AS2914) covering the announcement.

GIN will cease to announce any prefixes for which a valid covering RPKI ROA with the relevant origin AS is no longer available within 3 business days of such an event taking place. This policy will apply even in instances where no conflicting RPKI ROA exists for the announced prefix.