Version 4 (modified by suresh.krishnan@…, 3 years ago) (diff)


Typical INTernet Area Issues

Certain internet area related issues show up time and time again when the Area Directors in the IETF Internet Area (or members of the Internet Directorate or IoT Directorate) complete reviews of Internet-Drafts. I-D authors are advised to address these issues ahead of time to smooth the path to RFC publication.

IPv6 Support

IPv6 should be the basis of all new protocol developments but there are still some issues overlooked by authors.

Multiple IPv6 Addresses per Interface

All interfaces have at least one IPv6 address: the link-local address. But, they can also have many more addresses obtained by stateless address autoconfiguration, DHCP, ... possibly in different prefixes. The list of addresses also changes daily or even more frequently.

Canonical Format of IPv6 Addresses

All IPv6 addresses in an I-D should be written according to RFC 5952.

IPv6 literals with ports

In URI, the format of IPv6 literals uses square brackets to differentiate the ':' of the IPv6 address and the ':' used to separate the layer-3 address and the layer-4 port such as in http://[2001:db8::cafe]:8080.

Example Addresses

When I-D includes examples, the addresses should be from one of the reserved ranges as specified in RFC6890 (e.g. 2001:DB8::/32 for IPv6, and the other documentation ranges for IPv4)

The blocks (TEST-NET-1), (TEST-NET-2),
and (TEST-NET-3) are provided for use in

MTU and Fragmentation

IPv4 and IPv6 have different minimum MTU on the link (68 and 1280 bytes) and protocols should be designed to leverage larger MTU.

Fragmentation is also done differently between IPv4 and IPv6 as fragmentation can occur on the path for IPv4, but only at the originating host for IPv6.


What happens when an encapsulated packet cannot be forwarded ? Should ICMP error message be generated ? To which destination ? Including which part of the inside packet ?

Extension Header Insertion/Deletion?

IPv6 Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node other than the node in the Destination Address field of the IPv6 header as per RFC8200. Intermediate nodes that wish to add extension headers need to create a new encapsulated IPv6 packet to do so.

Address privacy

IPv6 addresses of nodes are expected to be more visible on the Internet as compared with IPv4 due to the reduced need for NATs. RFC7721 explores a bunch of privacy and security issues related to this.