As a path vector protocol, Border Gateway Protocol (BGP) messages contain an entire Autonomous System (AS) path to each destination for breaking arbitrary long AS path loops. However, after observing the global routing data from RouteViews, we find that BGP AS Path Looping (BAPL) behavior does occur and in fact can lead to multi-AS forwarding loops in both IPv4 and IPv6. The number and ratio of BAPLs in IPv4 and IPv6 on a daily basis from August 1, 2011 to August 31, 2015 are analyzed. Moreover, the distribution of BAPLs among duration and loop length in IPv4 and IPv6 are also studied. Several possible explanations for BAPL are discussed in this paper. Private AS Number Leaking (PANL) has contributed to 0.20% of BAPLs in IPv4, and at least 1.76% of BAPLs in IPv4 were attributed to faulty configurations and malicious attacks. Valid explanations, including networks of multinational companies, preventing particular AS from accepting routes, also can lead to BAPLs. Motivated by the large number of PANLs that contribute to BAPLs, we also study the number and the ratio of PANLs per day in the 1492 days. The distribution of the private AS numbers in all of the PANLs is concentrated, and most of them are located in the source of the AS paths. The majority of BAPLs resulted from PANLs endure less than one day, and the number of BAPLs which are caused by two or more leaked private ASes are much larger than that of BAPLs which are caused by one leaked private AS. We explain for this phenomenon and give some advices for the operators of ASes.

With the rapid developmen of the Internet, the exhaustion of IPv4 address limited the development of the Internet for years. IPv6, as the core technology of the next generation Internet, has since been rapidly deployed around the world. As the widely deployed address configuration protocol, DHCPv6 is responsible for allocating globally unique IPv6 addresses to clients, which is the basis for all the network services. However, the initial design of the DHCPv6 protocol gave little consideration to the privacy and security issues, which has led to a proliferation of privacy and security accidents breaches in its real deployment. In this paper, to fundamentally solve a range of possible security and privacy issues, we propose a secure DHCPv6 mechanism, which adds authentication and encryption mechanisms into the original DHCPv6 protocol. Compared with other proposed security mechanisms for the DHCPv6, our method can achieve all-around protection for the DHCPv6 protocol with minimal change to the current protocol, easier deployment, and low computing cost.