On Wed, 16 Jul 2014, Brian E Carpenter wrote:
> The problem with both of these great inventions is that a single
> box on the path that takes the "drop" option breaks everything,
In that same vein, I wanted to object to this:
| 2.3.6. Destination Options for IPv6 (Number=60)
|
| 2.3.6.1. Uses
|
| The Destination Options header is used to carry optional information
| that need be examined only by a packet's destination node(s).
|
| 2.3.6.2. Specification
|
| This Extension Header is specified in [RFC2460]. At the time of this
| writing, no options have been specified for this extension header.
|
| 2.3.6.3. Specific Security Implications
|
| No security implications are known, other than the general
| implications of IPv6 extension headers.
|
| 2.3.6.4. Operational and Interoperability Impact if Blocked
|
| None.
Even if there were no destination options currently defined -- which in fact
is not true -- there is huge operational impact if this extension header is
routinely blocked: it would make it impossible to deploy any destination
options
at all. The damage caused to the Internet by such practices is a recurring
theme,
and it should be spelled out explicitly here. Failure to do so makes the
advice
that follows ("Pass packets that contain the Destination Options Header") seem
weak and ill-motivated.
In fact, however, an examination of the references in the IANA IPv6 options
registry indicates that the following destination options have been defined:
Hex Value Binary Value Description Reference
Status
act chg rest
0x04 00 0 00100 Tunnel Encapsulation Limit [RFC2473]
PS
0xC9 11 0 01001 Home Address [RFC6275]
PS
0x8B 10 0 01011 ILNP Nonce [RFC6744]
EXP
0x8C 10 0 01100 Line-Identification Option [RFC6788]
PS
The text in 2.3.6.2 needs to be reworked to mention these options.
Mike Heard
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
