Support Center

BGP IPv4 peer filter policy

The following is the NTT DATA filtering policy with its peers:

Inbound

• NTT DATA accepts only those prefixes of length /24 and shorter from traditional class A, B, and C space.
• NTT DATA 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 DATA will accept any properly registered prefix from our customers but will announce only /24 and shorter prefixes to our peers.
• All NTT DATA announcements are registered in one of the routing registries and included under as-set AS2914:AS-GLOBAL.

NTT DATA 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 DATA 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 DATA filtering policy with its peers:

Inbound

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

Outbound

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

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

Global IP Network Routing Registry

Attn: NTT DATA Global IP Network 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 DATA Global IP Network commences activities that can cause disruption to flow of data through Internet circuits, NTT DATA Global IP Network 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 DATA Global IP Network 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 DATA 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 DATA Global IP Network 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 DATA Global IP 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 DATA Global IP Network 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.

Bidirectional Forwarding Detection (BFD) with BGP

NTT DATA’s Global IP Network supports Bidirectional Forwarding Detection (BFD) with Border Gateway Protocol (BGP) to enhance network reliability. This implementation enables quick detection of failures, ensuring that BGP sessions drop within a minimum hold timer of 100 milliseconds when a failure is identified.

The integration of BFD with BGP significantly reduces the time it takes for the network to converge after a failure. This means that routes can be recalculated, and traffic can be rerouted more quickly, enhancing overall network performance.

The hello interval is set to 100 milliseconds, and the hold timer is three times the hello interval, or 300 milliseconds – a vast improvement from the 90 second hold timer of BGP alone.  Additionally, BFD allows for configurable detection intervals. This means that network operators can adjust the parameters based on their specific performance and reliability requirements.

BFD is not supported with ECMP/multi-hop BGP sessions.

BFD is not enabled by default. Contact the NOC for configuration.

BFD Hold Timers

We configure our BFD hold timers to default settings to ensure stable and reliable network performance. If a customer’s detection timer is shorter than 300 milliseconds, the BFD detection timer is 300 milliseconds. If a customer’s detection timer is longer than 300 milliseconds, the BFD detection timer will be set to match the customer’s detection timer.

Additional Benefits of BFD with BGP

• BFD can provide failure detection in the microsecond range, which is beneficial for high-performance applications that require immediate failover capabilities.
• BFD sessions can be established between routers to monitor the health of the link. If a session fails, BGP can quickly withdraw the affected routes, ensuring that traffic is not sent over a failed path.
• BFD is designed to scale efficiently, making it suitable for large networks. It can handle a high number of sessions without significantly impacting CPU or memory resources on routers.

SecureLink and Generalized TTL Security Mechanism

SecureLink

SecureLink (also known as SecureNet) is a security feature designed to reduce customer exposure to external reconnaissance and certain forms of DDoS attack. SecureLink assigns WAN IP addresses for customer interconnections with the Global IP Network from non-globally-routed address ranges. These addresses are not reachable from the public Internet, which prevents unsolicited traffic from targeting customer WAN interfaces.

Using non-routed addressing lowers resource consumption on customer devices and provides additional protection for both IPv4 and IPv6 interconnections. ICMP packets directed at SecureLink-assigned addresses are also discarded within the GIN backbone. SecureLink may be applied independently to IPv4 and IPv6 sessions, with one or both sessions using the protected address space.

SecureLink is available at no additional charge. New customers may request SecureLink during provisioning, and existing customers may open a ticket with the NOC to have their interconnections renumbered into the SecureLink address ranges.

Generalized TTL Security Mechanism (GTSM)

The Generalized TTL Security Mechanism (GTSM), defined in RFC 5082, is a control-plane protection method that enhances the security of BGP sessions. GTSM uses the predictable behavior of the IP Time-to-Live (TTL) field to ensure that only packets from directly connected peers reach the route processor (RP).

When GTSM is enabled, BGP packets must arrive with a TTL of 255. Packets originating from off-path or remote sources will have decremented TTL values and are discarded in hardware before reaching the RP. This reduces susceptibility to spoofed BGP traffic, route processor flooding, and certain DDoS conditions.

Because GTSM requires matching TTL parameters on both ends of a session, it must be coordinated between peers. Customers wishing to enable GTSM on their sessions with GIN may request assistance through the NOC. GTSM is available at no additional cost.

Comparison of SecureLink and GTSM

The table below summarizes the distinctions between SecureLink and GTSM:

NTT DATA’s Global IP Network has chosen to focus on SecureLink as well as deploying Generalized TTL Security Mechanism (GTSM) because SecureLink provides broader and more customer-relevant protection. Whereas GTSM is limited to securing BGP sessions against a narrow class of attacks, SecureLink protects customer WAN interfaces from all external unsolicited traffic by using protected, non-globally-routable IP ranges within our backbone. This approach reduces DDoS exposure, preserves customer edge resources, and works across both IPv4 and IPv6.

By offering SecureLink free of charge, we provide a solution that not only complements protocol-level protections like MD5 but also delivers tangible security benefits for all customer traffic, not just BGP.

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 DATA 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 Global IP Network equipment and ASNs

Parties seeking to announce prefixes originating from Global IP Network-operated equipment or originating from a Global IP Network-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.

Global IP Network 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.