Jeff Doyle


Upcoming Events

Interop NY
Oct. 1-5

Interop is the only event to give you a comprehensive and unbiased understanding of all the latest innovations-including cloud computing, virtualization, security, mobility and data center advances-that help position your company for growth.

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 »

Tags: , ,

Channel: Networking & Mgmt, Next Gen Network, IPv6 Tech Center

See more from this blogger

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

I discussed in a previous article the necessity of abandoning IPv4 thinking when creating IPv6 address designs, and how our deeply ingrained need to conserve addresses can muddle our thinking. Nowhere does this conservative aversion to address waste snarl at us as menacingly as when we consider – completely compliant with the recommendations of ARIN and other RIRs – assigning /64 subnets to point-to-point links.

"You want me to allot a subnet with 18 million trillion addresses to a link that will only ever use two of them? Are you kidding me?" We know all the arguments for what we get in exchange for squander: Easier address management with one-size-fits-all subnets; simpler address interpretation; scaling; flexibility.

But still. Only using two addresses out of 18 million trillion? (Saying "million trillion" is a lot of fun if you imitate Carl Sagan’s voice.) Well, ask yourself when a /64 is acceptable.

Most people would say they can accept it on a regular LAN or VLAN segment. All righty then. To be fair, let’s take a really big LAN. Say, 5000 devices. Is a /64 acceptable there? Yes, you say? So we’re wasting (1.8 x 1019) – 5000 addresses instead of (1.8 x 1019) – 2 addresses. The difference between 5000 and 2 relative to 18 million trillion is miniscule. It diminishes to practically nothing. If it were any smaller it would be the amount I’m being paid to write this.

And yet a /64 on a LAN is acceptable and a /64 on a point-to-point link is not. IPv4 thinking can twist our reason. All of this does not mean there are not reasons to use a prefix other than /64 on point-to-point links – it only means address waste is not one of them. In fact, there are dueling RFCs on the topic.

RFC 3627 makes its case right in the title: "Use of /127 Prefix Length Between Routers Considered Harmful." The central argument in the document, however, is not as striking as the title suggests. Here it is:

  • When you use a /127 prefix on a point-to-point link, you have exactly two addresses available: PREFIX::0/127 and PREFIX::1/127. The problem the RFC cites is that the router being assigned PREFIX::1/127 might add the Subnet-Router Anycast address, which would be PREFIX::0/127. Then the router on the other end of the link, configured with PREFIX::0/127 will fail the Duplicate Address Detection test.


    Page:  1 | 2 |3 |4 |5 |Next Page »

    Related Reading


    More Insights




  • Currently we allow the following HTML tags in comments:

    Single tags

    These tags can be used alone and don't need an ending tag.

    <br> Defines a single line break

    <hr> Defines a horizontal line

    Matching tags

    These require an ending tag - e.g. <i>italic text</i>

    <a> Defines an anchor

    <b> Defines bold text

    <big> Defines big text

    <blockquote> Defines a long quotation

    <caption> Defines a table caption

    <cite> Defines a citation

    <code> Defines computer code text

    <em> Defines emphasized text

    <fieldset> Defines a border around elements in a form

    <h1> This is heading 1

    <h2> This is heading 2

    <h3> This is heading 3

    <h4> This is heading 4

    <h5> This is heading 5

    <h6> This is heading 6

    <i> Defines italic text

    <p> Defines a paragraph

    <pre> Defines preformatted text

    <q> Defines a short quotation

    <samp> Defines sample computer code text

    <small> Defines small text

    <span> Defines a section in a document

    <s> Defines strikethrough text

    <strike> Defines strikethrough text

    <strong> Defines strong text

    <sub> Defines subscripted text

    <sup> Defines superscripted text

    <u> Defines underlined text

    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. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
     

    IPv6 Reports

    Research and Reports

    Storage Virtualization Guide
    May 2012

    Network Computing: May 2012

    TechWeb Careers