Security Considerations for 6to4
RFC 3964

[Ballot discuss]
In 3.1, the document says:

  o  Disallow traffic that has private, broadcast or reserved IPv4
      addresses in tunnels, or the matching 6to4 prefixes.

It is not clear whether the "reserved IPv4 addresses" mentioned
here include the unallocated address space, or only those
set aside for special purposes.

This is important because of the relative work involved between
tracking currently unallocated space and tracking space set
aside.  Keeping up-to-date filter lists for the first is a major
undertaking, and there are screams of pain from the first
provider to get an allocation from a previously unallocated
block.  Things like Team Cymru's Bogon reference page
and route server help, but it is still a lot of work that
*everyone* has to do.

In general, the draft is very free with describing mitigations
that impose a hefty (and unspecified burden)--for example:

  Malicious native IPv6 nodes could be caught easily if ingress
  filtering was enabled everywhere in the IPv6 Internet.

I think the draft needs to describe the amount of effort associated
with the mitigation, and to focus on *who* needs to do the work.
Work that can be done by the 6to4 relay operator has a hope
of success--work that relies on *anything* being "enable everywhere"
does not.  Section 6.2 does this to some extent, but I think
the document would be more valuable if it were extended greatly.


Section 4.2.6 says:


Further, when someone is filing complaints to the owner of
  192.88.99.0/24, they notice multiple WHOIS records and see a pointer

At least at the moment, this is not accurate.  A single record is
returned from ARIN with a pointer to IANA, noting that it is reserved and
giving a reference to 3068:

NetRange: 192.88.99.0 - 192.88.99.255
CIDR: 192.88.99.0/24
NetName: IANA-192
NetHandle: NET-192-88-99-0-1
Parent: NET-192-0-0-0-0
NetType: IANA Special Use
Comment: This block is reserved for special purposes.
Comment: Please see RFC 3068 for additional information.
Comment:
RegDate:
Updated: 2002-09-16

[Ballot discuss]
In 3.1, the document says:

  o  Disallow traffic that has private, broadcast or reserved IPv4
      addresses in tunnels, or the matching 6to4 prefixes.

It is not clear whether the "reserved IPv4 addresses" mentioned
here include the unallocated address space, or only those
set aside for special purposes.

This is important because of the relative work involved between
tracking currently unallocated space and tracking space set
aside.  Keeping up-to-date filter lists for the first is a major
undertaking, and there are screams of pain from the first
provider to get an allocation from a previously unallocated
block.  Things like Team Cymru's Bogon reference page
and route server help, but it is still a lot of work that
*everyone* has to do.

In general, the draft is very free with describing mitigations
that impose a hefty (and unspecified burden)--for example:

  Malicious native IPv6 nodes could be caught easily if ingress
  filtering was enabled everywhere in the IPv6 Internet.

I think the draft needs to describe the amount of effort associated
with the mitigation, and to focus on *who* needs to do the work.
Work that can be done by the 6to4 relay operator has a hope
of success--work that relies on *anything* being "enable everywhere"
does not.  Section 6.2 does this to some extent, but I think
the document would be more valuable if it were extended greatly.


Section 4.2.6 says:


Further, when someone is filing complaints to the owner of
  192.88.99.0/24, they notice multiple WHOIS records and see a pointer

At least at the moment, this is not accurate.  A single record is
returned from ARIN with a pointer to IANA, noting that it is reserved and
giving a reference to 3068:

NetRange: 192.88.99.0 - 192.88.99.255
CIDR: 192.88.99.0/24
NetName: IANA-192
NetHandle: NET-192-88-99-0-1
Parent: NET-192-0-0-0-0
NetType: IANA Special Use
Comment: This block is reserved for special purposes.
Comment: Please see RFC 3068 for additional information.
Comment:
RegDate:
Updated: 2002-09-16

[Ballot discuss]
Section 4:
The text notes that "the IPv4 address blocks 8.0.0.0/24 and 9.0.0.0/24 are only used for demonstrative purposes, and represent global IPv4 addresses". These two address blocks are assigned to BBN and IBM and shouldn't be used for examples.  Per RFC 3330, 192.0.2.0/24 is set aside for use in "for use in documentation and example code".

Is there a reason that these two in-use address blocks are being used in examples?

I didn't check the IPv6 examples.