Jeff Doyle


Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

Vendor NewsFeed

More Vendor NewsFeed »

See more from this blogger

The Fear And Loathing Of /64s On Point-To-Point Links

In the other corner is RFC 6164, “Using 127-Bit IPv6 Prefixes on Inter-Router Links.” This document starts off saying pretty much what I said above about the concerns of RFC 3627: That Subnet-Router Anycast addresses shouldn’t be a problem on point-to-point links. Then it gets to a more valid concern: Ping-pong attacks.

A ping-pong attack exploits implementations which follow the now obsolete RFC 2463 specification of ICMPv6. That RFC says that if an IPv6 interface receives a packet that belongs to the subnet to which the interface is attached, but not to an address of that interface, forward the packet back onto the subnet. So an attacker can flood a bunch of packets to unused addresses on a link and the packets will bounce back and forth (ping-pong) between the two routers, using up bandwidth and router resources.

One way to guard against such an attack, and the position of RFC 6164, is to insure that there are no unused addresses on the point-to-point link – use a /127, so there are only two addresses. But there is a better way to guard against the ping-pong vulnerability, and that is to use routers that support the modern version of ICMPv6. RFC 4443 corrects the error in the earlier specification, requiring an interface to drop a packet addressed to an address on the subnet rather than forward the packet back onto the subnet.

RFC 4443 has been around since March of 2006. There is no reason for a vendor to continue to support a version of ICMPv6 that has been obsolete for five years. And it is, in my opinion, absurd for a vendor to advocate using a /127 subnet on point-to-point links, in violation of all other IPv6 recommendations, simply to avoid updating their ICMPv6 code. Rather than bend your IPv6 address design to accommodate a vendor inadequacy, pressure your vendor to modernize.

There is another potential vulnerability citied in RFC 6164: If a point-to-point link supports Neighbor Discovery Protocol (NDP), a packet to an unused IPv6 address on the subnet will cause an Incomplete entry in the routers’ neighbor cache and cause a Neighbor Solicitation message to be sent on the link. A flood of packets to many unused addresses might fill up a neighbor cache, and congest the link with NS messages, constituting a DoS action. RFC 6164 recommends preventing such an attack by, again, using /127 prefixes.


Page: « Previous Page | 12 3 | 45  | Next Page »


Related Reading


More Insights


Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
 
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

IPv6 Reports

Research and Reports

August 2013
Network Computing: August 2013



TechWeb Careers