NIST IPv6 document

Jeff Wheeler jsw at inconcepts.biz
Thu Jan 6 05:50:39 UTC 2011


On Thu, Jan 6, 2011 at 12:17 AM, Joe Greco <jgreco at ns.sol.net> wrote:
> However, that's not the only potential use!  A client that initiates
> each new outbound connection from a different IP address is doing
> something Really Good.

No, Joe, it is not doing anything Good.  This would require the
software being written to make such random address selection, add more
entries to the router's NDP table, and it would DoS the box's own
router if an outbound scan were initiated from the host machine.
Again, you totally fail to understand the problem.  I should just
attach a "facepalm" graphic to my reply and stop bothering with your
idiocy, but it is important that as many people as possible understand
these issues.  Every additional person who is expressing concern to
their vendors brings us closer to a solution.

In addition, if the machine can choose another random IPv6 address in
the /64 for each new outgoing connection, it could just as easily
source all its outgoing connections from ... a single IPv6 address
that does not accept any incoming connections.  I will grant that this
does not prevent "magic packet" attacks against bugs in the machine in
kernel space, and that the machine could be the recipient of a DoS
attack; but your proposed solution has no advantage in the case of,
say, SQL Slammer 6, or other attacks exploiting vulnerabilities in
user-space.

On Thu, Jan 6, 2011 at 12:25 AM, Owen DeLong <owen at delong.com> wrote:
> Is there any reason we really need to care what size other people use for their Point to Point
> links?
>
> Personally, I think /64 works just fine.
>
> I won't criticize anyone for using it. It's what I choose to use.

You should care what size you choose, Owen.  I would if I was your
customer.  There are several reasons why.  If you configure a /64 on a
point-to-point interface e.g. SONET, some current platforms will
bounce any "scan" packets back and forth between the two hosts until
the TTL expires, which means an attacker can saturate the
point-to-point link with two orders of magnitude less attack traffic
than the link capacity.  This is very bad.

Also, if the link is a LAN, you are vulnerable to the ARP/NDP problem.
 This may be a per-interface issue on your box, or it may be a global
one.  In the per-interface case, most likely, the failure mode will be
okay; but some vendors (including Juniper?) will eventually expire the
ARP/NDP entry even though there is active traffic, and may be unable
to re-learn it when needed due to the attack, which would break the
link between routers.  On the other hand, if it's a global issue, it
will break NDP on the entire router, affecting all interfaces by
whatever the platform's failure mode is.  Obviously, that is worse.

This is why "RFC compliant" is wrong, Owen.  That a learned,
experienced person such as yourself has no clue what the underlying
problem is exemplifies my point: much, much more noise needs to be
made about this issue.  A lot of smart people have known about it for
years but nothing is being done.

Anyone can choose not to use /64 on their point-to-point links with no
consequence to their business.  Customers aren't going to choose
another vendor because they are likely never even aware of it.  The
operational problem is that customers will want it on the PE/CE LANs,
hosting center LANs, and so on; and right now, if you tell them "we
can't do that," they have trouble believing you because the standard
says otherwise, and a lot of other networks are currently doing it
(because they think they don't have a choice other than to lose
potential customers.)

However, if you are running /64 instead of something like /124 on your
VLANs or SONET circuits between routers, you should change this
practice as soon as practical.  Not doing so once you have been
educated about this problem because it is "the standard" is very
stupid.  Pretty much every major transit network has figured this out
and are doing it on their interfaces to BGP customers, too, either
optionally, by default, or as the only choice.

The industry standard must change to be non-hostile toward choosing a
smaller subnet size than /64 to give coverage to those of us who do
understand what we are doing as we roll out IPv6 to customers.

--
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts




More information about the NANOG mailing list