Best practice is to use a manual /127 address for point to point addressing described here RFC2373

for EUI-64 ERFC 2373 dictates the conversion process, which has two steps. The first is to convert the 48-bit MAC address to a 64-bit value. To do this, we break the MAC address into its two 24-bit halves: the Organizationally Unique Identifier (OUI) and the NIC specific part. The 16-bit hex value 0xFFFE is then inserted between these two halves to form a 64-bit address.

I understand perfectly where you would use the /127 manual address assignment , but I cant really see the benefits in using the EUI-64. unless i am totally missing the actual purpose of this address function.

can someone kindly shed some light on the EUI-64 use cases specifically in a ISP WAN topology if possible. or point me in the direction of some reading material please.

  • 1
    Note that RFC 2373 is obsoleted by RFC 3513, which is obsoleted by RFC 4291.
    – belacqua
    Commented Feb 14, 2014 at 17:50

3 Answers 3


This is the subject of a large debate that's been going on for a while.

When it comes down to it, using a /127 on a point-to-point link isn't really a terrible idea. RFC6164 illustrates that it actually may be a good idea to use a /127 - it identifies some of the big issues for moving to a /127 on a P2P link, and talks about the steps that have been taken to mitigate, if any. The fear of ping-pong attacks was mitigated in the most recent version of ICMP, and neighbor cache exhaustion attacks are actually eliminated on P2P links by using a /127 prefix.

EUI-64 is generally preferable on user subnets, since SLAAC generally breaks if /64 subnets are not used. On P2P links where SLAAC is not used, it's not that big of a deal.

In conclusion, I believe the general consensus is that using a /127 is not a big deal - in fact you may want to allocate a single /64 for all your P2P links. Your routing table may take a small hit since all of the P2P prefixes won't be easy to summarize, but it's unlikely to be a significant problem. Just keep the RFC I mentioned in mind, and make sure you follow the guidelines it provides.

  • 3
    SLAAC doesn't "generally break", it applies to a LAN only when the prefix length is exactly 64. (my warparty is still out hunting down the geniuses responsible for that.)
    – Ricky
    Commented Jun 24, 2013 at 19:31

Using a /127 is convenient when manually configuring point-to-point links. I usually reserve a /64 in my addressing plan (for clarity and consistency with other non-/127 networks) and then configure xxxx:xxxx:xxxx:xxxx::a/127 on one side and xxx:xxxx:xxxx:xxxx::b/127 on the other side of the link.

EUI-64 addresses are used a lot when auto-configuring interfaces. Link-local (fe80::/10 addresses) often use them, and if the system receives a router advertisement with prefix information it will take the /64 prefix as the first 64 bits of its address and the EUI-64 as the last 64 bits of the address, to form a full 128 bit IPv6 address. All without the need for manual configuration or a DHCP server.

  • I edited your address notation to :: and ::1 since, by definition, you cannot have anything other than 0 and 1.
    – Olipro
    Commented Jun 24, 2013 at 22:34
  • Olipro: you are wrong. ::a and ::b are perfectly valid for a /127. I edited it back. Commented Jun 25, 2013 at 6:03
  • 1
    Ah yes, of course, the last bit in 0xa is 0 and 0xb is 1, meaning the subnet is effectively xxxx:...::a/127
    – Olipro
    Commented Jun 25, 2013 at 14:51

Using a /127 isn't terrible, but letting it go into your backbone as a /127 is.

The reason for this is that, essentially, most modern router TCAMs can typically only handle up to 64 bits of address width at a time - this means that if you're in a situation where all routes are /64 or shorter, lookups can occur in a single cycle. Anything longer and it has to perform another lookup operation. Even on a TCAM that only has 32 or 48 bit width, going beyond /64 is obviously still significant.

So, my personal recommendation is to allocate a /64 for every P2P link even if you only use a /127 on the wire - that way, when you bring up your routing protocol, you can then aggregate the /127 to a /64.

My personal favourite, however is to allocate a reasonable chunk of your IPv6 space purely for facilitating P2P links (in my case, I reserved a /48) - this /48 is then blocked on all network edge interfaces at ingress as a destination. In this way, you're free to just go ahead and use a /64 on your P2P links and still have traceroutes, ICMP errors et. al work, but you are not vulnerable to NDP attacks from outside.

Obviously not everyone is going to care about this and if the additional cost of using longer prefixes is acceptable to you (or you have super-duper 128 bit TCAMs) then you can of course ignore everything above. How scalable do you want your network to be?

  • We are using a Juniper MX80 platform and the extract below would lead me to believe TCAM should not be a critical issue MX80 is a single MPC using the new Trio ASICs, which means that it has roughly double the capacity of the original DPCs. See MX80 TCAM for a full explanation
    – DrBru
    Commented Jun 24, 2013 at 11:25
  • What you linked is referring to MAC addresses, it says nothing about IPv6 routes. Additionally, any router can generally have prefixes all the way up to /128 - the issue is the number of cycles the TCAM has to go through in order to find the match.
    – Olipro
    Commented Jun 24, 2013 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.