On 1/24/2011 7:18 AM, bmanning@vacation.karoshi.com wrote:

this results in -very- sparse matrix allocation - which is fine, as long as you believe that you'll never run out/make mistakes. personally, i've use /126 for the past 12 years w/o any problems.

There isn't an increased mistake risk factor using /126 out of a /64 assigned and your mistake factor probably slightly increases just assigning a bunch of /126 out of a single /64. We use /126 internal links, /128 loopbacks (these we do streamline), and customer links are generally /64, as currently we have no choice but use SLAAC + DHCPv6 (thanks Cisco!). That being said, while renumbering my network, I noted several link address mistakes. Had nothing to do with the /126 or /64 boundaries. I just left out one of the nibblet sets, and :: notation gladly makes that into a valid address. This leads me to believe that using short hand is likely to lead to more mistakes. Jack

On Jan 24, 2011, at 4:22 PM, Crist Clark wrote:

...

RFC 3627

Actually makes it pretty clear. It's IPv6 think where the subnet-router anycast address is the prefix followed by all zeros. So, while IPv6 does not reserve the all-ones address, the all-zeroes address is still reserved. Owen

All of the (mostly religious) arguments about /64 versus any smaller subnets aside, I'm curious about why one would choose /126 over /127 for P-to-P links? Is this some kind of IPv4-think where the all-zeros and all-ones addresses are not usable unicast addresses? This isn't true in IPv6 (of course, it's not strictly true in IPv4 either). Is there another reason?

I setup a p2p /127 link and found that BGP would not peer over the link; Changing to /126 resolved the problem. I never looked into it further because I had intended to use /126 from the start. My guess is that while BGP should be a unicast IP, Cisco's implementation uses an anycast in some cases, disregarding the configured unicast address. Just one practical example...

-------- Original Message -------- Subject: Re: IPv6: numbering of point-to-point-links From: Randy Bush <randy@psg.com> To: Blake Hudson <blake@ispn.net> Cc: nanog@nanog.org Date: Monday, January 31, 2011 3:26:26 PM

...

I setup a p2p /127 link and found that BGP would not peer over the link; on whose equipment and image?

randy This was with a cisco 7200 - IOS 12.4 over a HE tunnel. Debugging BGP showed no activity until the interface mask was changed, as if BGP was not active and was not attempting to peer. The remote peer's state would only display as IDLE. After changing the interface mask to /126 peering came up instantly and I did notice some BGP logging that related to the 0 address on the network.

On Mon, Jan 31, 2011 at 09:13, Blake Hudson <blake@ispn.net> wrote: ....

I setup a p2p /127 link and found that BGP would not peer over the link; Changing to /126 resolved the problem. I never looked into it further because I had intended to use /126 from the start. My guess is that while BGP should be a unicast IP, Cisco's implementation uses an anycast in some cases, disregarding the configured unicast address.

Just one practical example...

I suspect this is very platform/version specific, as I have run BGP on a Cisco 6500 (SXI<mumble>) to a Juniper MX and we had no trouble with a /127 (although prepared to move to a /126 or whatever if needed). As always, your environment will vary. I would open a TAC case on the principal that it should work.

Doh, I meant the /80 of 1C for interconnects. xxxx:xxxx:zz::1C:YYYY:1 and :F in a /112 ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net<mailto:skeeve@eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 25/01/11 12:43 AM, "Skeeve Stevens" <Skeeve@eintellego.net<mailto:Skeeve@eintellego.net>> wrote: Lasse, We use /112's – last chazwazza being 65k addresses… Requires little effort in remembering the ranges…. With one end being :1 and the other :F This leaves more than enough addresses for HSRP/VRRP and all the other things like it. Also means we can introduce addressing on the link for diagnostics quite easily. We actually use the /96 of 1C (to mean 1nterConnect) - makes it recognisable to engineering staff. There is the issue of the pingpong affect, but I'm hoping vendors (if they haven't already) will introduce features to protect against it when (if) they implement RFC4443. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net<mailto:skeeve@eintellego.net><mailto:skeeve@eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 24/01/11 11:48 PM, "Lasse Jarlskov" <laja@telenor.dk<mailto:laja@telenor.dk><mailto:laja@telenor.dk>> wrote: Hi all. While reading up on IPv6, I've seen numerous places that subnets are now all /64. I have even read that subnets defined as /127 are considered harmful. However while implementing IPv6 in our network, I've encountered several of our peering partners using /127 or /126 for point-to-point links. What is the Best Current Practice for this - if there is any? Would you recommend me to use /64, /126 or /127? What are the pros and cons? -- Best regards, Lasse Jarlskov Systems architect - IP Telenor DK

On 1/24/2011 4:20 PM, Ray Soucy wrote:

That said. By not using the 64-bit boundary you may be sacrificing performance optimizations with today's processors that lack operations for values larger than 64-bits.

Is this an issue for any known vendors today?