The Internet Engineering Task Force (IETF), the international group of engineers and professionals that defines technical Internet standards, met in Seoul, Korea, to work on several key issues.
By Guillermo Cicileo
The two main groups currently working on IPv6 met in Seoul: v6ops and 6man.
During the v6ops meeting, a new version of the document on IPv6 network design was presented under a new name —Routing-Related Design Choices for IPv6 Networks— designed to specify that the group only deals with routing issues. From the point of view of our region, it is important that we contribute based on our experience in IPv6 network operation.
Another document was also presented, this one titled Enterprise Multihoming using Provider-Assigned Addresses. Its purpose is to offer a multihoming solution without NAT-NPT for organizations that don’t have IP addresses.
One of the main topics discussed by 6man was the analysis of the IPv6 documents so they can become Internet standards. There were also discussions about the possibility of modifying the original text of RFC 2460 to describe the difficulties of inserting Extension Headers in a path (instead of not allowing this as in the original version), leaving the door open to changes to the end-to-end model.
One of the most relevant documents presented at the grow meeting refers to the default behavior of BGP when a session does not have any applied policies. This document proposes filtering all announcements when no policy is configured. While this may be considered a healthy measure for having greater control over BGP announcements, it is important to consider the implications it may have for existing implementations.
Participants at the idr group meeting discussed the problems they faced when requesting codepoint 30 from the IANA for the large communities attribute. The codepoint was already being used without authorization. There were some proposals for having experimental attributes instead of depending on codepoint assignments.
Several presentations addressed flowspec, a technology which can be used to prevent DDoS attacks. As for route leaks, there is a proposal for implementing “roles” in BGP sessions to avoid incorrectly propagating announcements that are received. In addition, a draft was submitted once again for incorporating SPF (Dijkstra) into BGP. In this case, one of the Area Directors suggested that the proposal should be not discussed within idr, but instead within the rtgwg group or another context, as it would be a new protocol and not a change to BGP.
Finally, the sidr group discussed the possibility of finalizing the group’s work and continuing some proposals within the framework of the new sidrops group, for which a charter defining its objectives has already been proposed. A document was presented describing the implementation of RIPE’s validation software with the purpose of obtaining an independent review. Several other RPKI implementation interoperability issues were also debated, and there was a proposal to conduct some testing involving the RIRs during 2017.
The full article is available at: