Folks,
Some comments:
* Section 4.8 ("Defining New Extension Headers and Options")
Specification of new EHs would bring problems. And, for instance,
recommending a specific format for new EHs does not really help.
A key problem with the Uniform Format for IPv6 Extension Headers
described in this section (originally specified in RFC6564) lies in that
both IPv6 Extension Headers and Transport Protocols share the same "Next
Header" registry/namespace. Thus, given an "unknown Next Header value",
it is impossible to tell whether the aforementioned value refers to an
IPv6 Extension Header that employs the aforementioned uniform format, or
an "unknown" upper-layer protocol (e.g. an "unknown" transport
protocol). That is, while this document (and RFC6564) specifies the
syntax for a Uniform Format for IPv6 Extension Headers, it does not
provide a mechanism for a node to identify whether the aforementioned
format is being employed in the first place.
The current impossibility to parse an IPv6 header chain that includes
unknown Next Header values results in concrete implications for the
extensibility of the IPv6 protocol, and the deployability of new
transport protocols. Namely,
o New IPv6 extension headers cannot be incrementally deployed.
o New transport protocols cannot be incrementally deployed.
We've elaborated on this topic in draft-gont-6man-rfc6564bis. One
possible way to address this problem is simply to ban the specification
of new EHs. Another is to d something along the lines of
draft-gont-6man-rfc6564bis. However, the current text seems misleading
-- for instance as is, it doesn't buy much to have a "unified format"
for new EHs, since you don't really know how to parse that EH in the
first place.
* Section 3:
Regarding the "version" field, it might be useful to note that it should
be checked that, upon receipt of a packet, it is actually 6. It
shouldn't matter, but in practice, it might. Please see:
<http://blog.si6networks.com/2016/02/quiz-weird-ipv6-traffic-on-local-network.html>
for a real-world scenario.
* Security Considerations section
I think the security considerations section should be augmented.
For example, the Extension Headers have been known to be useful for the
evasion of security controls. While in theory this need not be the case,
in practice it is.
* Appendix B ("CHANGES SINCE RFC2460")
I think this section should summarize the changes since RFC2460 but
*not* on a "per I-D version basis". That is, "as is", it is hard to
figure out what has changed since RFC2460.
Thanks!
Best regards,
Fernando
On 02/01/2017 08:49 PM, The IESG wrote:
>
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document:
> - 'Internet Protocol, Version 6 (IPv6) Specification'
> <draft-ietf-6man-rfc2460bis-08.txt> as Internet Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2017-03-01. Exceptionally, comments may be
> sent to iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document specifies version 6 of the Internet Protocol (IPv6).
> It obsoletes RFC2460
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc2460bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc4443: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (Draft Standard - IETF stream)
> rfc3168: The Addition of Explicit Congestion Notification (ECN) to IP (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@xxxxxxxx
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492