News

 

 

Please note that depending on the visibility of the moon, either Thursday 13 or Friday 14 May 2021, will be a public holiday in Mauritius.

AFRINIC Offices shall be closed and will resume business on the next business day.

Any urgent issues can be addressed to:

  1. new-member@afrinic.net for queries or clarifications regarding how to become an AFRINIC member.
  2. hostmaster@afrinic.net for additional resources, and general queries relating to resources management.

 

 

 

 

IPv6 Extension Headers

IPv6 Extension Headers have been a part of the core IPv6 specification as detailed in RFC8200. They offer supplementary information about IPv6 packets on how they are processed or routed, such as Hop-by-Hop Options. The Hop-by-Hop Options header is not inserted or deleted.

Still, it may be examined or processed by any node along a packet's delivery path until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field the IPv6 header.

The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header (taken from RFC 8200).

Their implementations within several IPv6 deployments have led to many security issues such as the 'Cisco IOS Software IPv6 Virtual Fragmentation Reassembly Denial of Service Vulnerability' or IPv6 Hop-by-Hop options use-after-free.

 

IETF works on IPv6 Extension Headers

Several IPv6 engineers came together to write the 'Operational Implications of IPv6 Packets with Extension Headers

The document highlights the issues regarding IPv6 Extension Headers and why they are dropped intentionally on the public Internet.

 

Packet forwarding constraints

Many consumer-grade routers have limitations regarding the length of IP header they can process. With IPv6 Extension Headers, this can lead to throughput reduction or simply dropping packets.

 

ECMP and Hash-based Load-Sharing

Many routers need to infer more information regarding how to do load sharing. The IPv6 flow label header would be helpful for this purpose as it would avoid having to process several IPv6 Extension Headers before making a decision.

Unfortunately, many routers (approximately 20-30%) deployed fail to use the IPv6 flow label header properly, and therefore, IPv6 Extension Headers are often dropped in those cases.

 

Security issues with IPv6 Extension Headers

Many routers have a default deny policy in security operations. This means that IPv6 Extension Headers are often dropped by default. Additionally, when Access Control Lists are set, they are often done in a manner where IPv6 Extension Headers can cause a security bypass. Therefore, for security reasons, they are usually dropped. Additionally, due to the processing requirements of those additional headers, many firewalls prefer to drop them as they can be used as a Denial of service vector.

 

Conclusion

The IETF draft on 'Operational Implications of IPv6 Packets with Extension Headers' offers an excellent in-depth discussion to Network Engineers on the implications of IPv6 extensions on the operation side.

In this blog, we gave an overview to Network and Systems Engineers. We encourage readers to go through the Internet-Draft and, if possible, offer suggestions to the IETF v6ops Working Group

 

 

 


 

About Author

Logan Velvindron
Infrastructure Security Engineer 

He experiments with new security technologies that have business value. In addition to this, he is a contributor to the Internet Engineering Task Force both as a specification developer, Security Area/Internet of Things Directorate member and a Working Group chair. He has managed and led several IETF hackathons during both African Internet Summit and IETF meetings.