Top of Page

Links to move inside this page.

  1. HOME
  2. Technology
  3. IIJ Technology (archives)
  4. Source Address Validation

Source Address Validation

Source Address and Communication

IP packets has address information for both the source and the destination. When begin in communication, the source sends the IP packet to the destination. The destination returns a response packet to the source address of the IP packet. If the source address is not correct, the destination cannot correctly return a response.

Improper Source Address

On the internet, the following types of address are improper source address.

  • Private Address, Unique Local IPv6 Unicast Address (ULA) 
  • Unassigned Internet address
  • Special address such as, :: , documentation address and multicast address.

In more precise terms, a normal state is one in which communication are conducted using an assigned address from ISP, an improper state is when a source address differs from assigned address from ISP.

There are several conceivable reasons as to why a source address may be different than an assigned address. One cause could be a problem with software. It is not uncommon for software defects to result in the attachment of incorrect IP address or incorrect NAT behavior. Another cause could be spoofed IP address by malevolent software. Attackers engaging in spreading worms. DoS, or the other attacks may spoof the source address to disguise their identify or to make response difficult.

Over recent years, we have seen an increasing amount of source address spoofing associated with DoS attacks and other improper Internet communication. Smurf attacks are one of the main types of attacks that use spoofed source address. Other cases of source address spoofing have been associated with SYN flood attacks and ICMP flood attacks. Source address spoofing not only disrupts normal communication, but it also places extreme loads on ISP backbones and customer network environments due to the enormous volume of needless communication flow.

Source Address Validation Technology

IIJ enables Source Address Validation that verify the legitimacy of source address, and rejects spoofed source address packets.

The following are some of the technologies used for verify the legitimacy of the source address:

ACL(Access Control List)

  • Packet filtering
  • Application of a list of source IP address that are allowed to flow into a network.

uRPF (Unicast Reverse Path Forwarding) Check

  • Use router path information
  • Confirm whether the incoming source IP address is from the original path

A uRPF check utilizes router path information to confirm the source address. As long as the path information remains correct, there is no particular need for management. More specifically, just as the destination address is used to search for a path address, and then on to the next forwarding destination, path information can be searched using the source address, comparing the interface of the forwarding destination and the interface of the incoming packet to perform a validity check.

The uRPF check method consists of several modes:

Strict mode

Confirms that the path to the packet source address and the incoming packet interface match perfectly.

Loose mode

Confirms whether the path leading toward the source address exists.

Source Address Validation Incorporated into IIJ Services

Mutual Connections between IIJ and other ISPs

Incorporates technology equivalent to uRPF loose mode.

Services for Business Customers

Internet Access Service Static routing of the IP address assigned by IIJ:
Equivalent to uRPF strict mode.
Portable address or dynamic routing:
Equivalent of uRPF loose mode.
IIJ FiberAccess/F Service
IIJ FiberAccess/Q Service
IIJ FiberAccess/C Service
IIJ DSL/F Service
IIJ DSL/A Service
IIJ ISDN/F Service
Equivalent to uRPF strict mode.
IIJ Dialup Advanced
Enterprise Dialup IP Service
IIJ Dialup Standard
Equivalent to uRPF strict mode (except for some access points).
IIJ Mobile Service/Type D
IIJ Mobile Service/Type E
IIJ Mobile Biz+ Service

Personal Services

IIJ4U Equivalent to uRPF strict mode (except for some access points).
IIJmio DSL/DF Service
IIJmio FiberAccess/DF Service
IIJmio DSL/SF Service
IIJmio FiberAccess/SF Service
IIJmio FiberAccess/DC Service
Equivalent to uRPF strict mode.
IIJmio Mobile Access
IIJmio Mobile Access/3G
IIJmio Mobile Access/PRO
Equivalent to uRPF strict mode (except for some access points.).
IIJmio High-speed Mobile/D Service
IIJmio High-speed Mobile/EM Service

Effect of Implementation on Communication

Under uRPF strict mode and ACL packet filtering, communication with a source address that is the same as the IP address space for using the access service that has been assigned by IIJ (or the IP address already owned by the customer and reported to IIJ to be used) are treated as normal communication. Alternately, packets with a different source than the source address used to link to the access service are rejected.

In general, strict mode has no effect on communication when only one Internet access service is used.

Effect of Implementation on Communications

However, under certain conditions where a multiple number of Internet access services are used in a specific manner, strict mode can negatively affect communication.

For example, an organization uses two Internet connection lines, each having its own assigned IP address:

  • Address assigned by Access Service A:, 2001:DB8:AAAA::/48
  • Address assigned by Access Service B:, 2001:DB8:BBBB::/48

Strict source address verify for Access Service B

When communicating using the Access Service B line, a problem will occur if the address assigned by Access Service A is used as the source address.

Effect of Implementation on Communication

Using the Access Service B, only packets using source address, 2001:DB8:BBBB::/48 linked to the access service will be allowed to pass through, while any packets using a different source address will be rejected. Accordingly, any packets with the source address assigned through Access Service A will be rejected when coming from the Access Service A line.

Even under this structure, there will be no effect on communication as long as the access service and assigned address correspond properly.

Effect of Implementation on Communication

In cases where the network structure may cause a discrepancy in access service and source address, we ask that customers revise their network so that address match, and that each connection service uses the correct address.

With ISP-to-ISP connections, or where networks have a redundant structure using multiple access lines, the upstream and downstream communication paths may be in an asymmetric state. According to uRPF strict mode, the path to the source address and the interface from which the packet comes do not match; consequently, even packets having a correct source address can be rejected. In other words, uRPF strict mode cannot be implemented under certain connection topologies.

In the preceding situation, uRPF loose mode can be used as the technology for confirming source address. Under uRPF loose mode, packets that have a source address that exists within the path information are allowed to pass through, and any other packets are rejected. This means that, for example, packets using private address and unused address (generally viewed as improper source address), as well as packets using multicast address or other special address are detected and rejected. However, the drawback here is that if the source address exists within the path information, even if that source address has been spoofed, the packet will be allowed through.

uRPF loose mode has no effect on customer communication, since only packets with a clearly improper source address are rejected. Prior to implementation, even packets containing a source address not located within the path information will arrive at the destination; however, the response from the destination will not be able to reach the source, preventing communication. In a post-implementation environment, packets with source address determined as improper are rejected before they can reach the destination. There is no change here in the sense that communication do not occur, but the benefit of implementation is a reduced level of unneeded packets moving within the network.

Enable Source Address Validation on your Network

The closer to the packet source, the more effective Source Address Validation is. When Source Address Validation is close to the source, unneeded communications can be rejected at a much quicker stage in the process, reducing the effect on an internal network. In addition, the closer to the source, the more detail with which a source address can be checked. This characteristic means that implementation of Source Address Validation not only on the part of the ISP, but also on the part of the customer's internal network results in much more effective source checking.

Enable Source Address Validation on your Network

IIJs' "SEIL" routers (SEIL/X1,SEIL/X2,SEIL/B1,SEIL/X86 Fuji, SEIL/Plus, SEIL/Turbo)  have the uRPF function. The SEIL provides Source Address Validation function to our customers. Our Customers are able to easily use the Source Addess Validation on their networks.

Since Source Address Validation does not have any effect on normal communication, customers may find it difficult to actually feel whether it is effective. But be assured that Source Address Validation will prevent damage to your networks that can be caused by worms or DoS attacks using spoofed source IP address. Both RFC2827 (BCP38) and RFC3704 (BCP84) recommend that all network administrators cooperate to help prevent source address spoofing.

In theory, if Source Address Validation were implemented not only on the IIJ network, but on all networks worldwide, we could eradicate from the Internet any attacks relying on source address spoofing.

At IIJ, we have actively engaged in Source Address Validation measures and education to reduce the effects of improper communication, providing an environment whereby our customers can use the Internet with greater safety and confidence.

Author: Yuhei Onohara

Network Service Section, Network Service Department, IIJ Network Division
Mr. Onohara joined IIJ in 2007. He worked on the implementation and operation of leased-line access services, and is now engaged in the development and operation of broadband services.

End of the page.

Top of Page