IPv6 Loopback/Point-to-Point address allocation

Mon Sep 11 22:08:51 UTC 2017

On 9/9/17, 12:06 PM, "NANOG on behalf of Kody Vicknair"
<nanog-bounces at nanog.org on behalf of kvicknair at reservetele.com> wrote:

>All,
>
>I’ve been doing some reading in preparation of IPv6 deployment and
>figuring out how we will break up our /32. I think I’m on the right track
>in thinking that each customer will be allocated a /48 to do whatever
>they wish with it.

Yes.

>
>I’ve read recent BCOP drafts that have been approved by the IETF:
>https://www.ripe.net/publications/docs/ripe-554

BCOP isn’t an IETF BCP. But that’s a really minor detail; BCOPs much
better operator input than most IETF activities (IMHO, as an active IETF
participant).

>It looks like the smallest subnet that should ever be assigned is a /64
>on a particular link.
>
>
>Some questions that come to mind with IPv6:
>
>In regards to Point to point links my thinking is this:
>Assign a unique /64 to each point to point link with these addresses
>being Globally routable. This seems to be what our IX providers do when
>assigning us an IPv6 address. Am I correct in this train of thought?
>Why/Why not?

Yes, the general guidance is to reserve a /64 for the link and configure a
very small subnet (like /127) on the interfaces, to avoid a ping-pong
attack.

>
>In regards to core loopback addressing my initial thoughts are as follows:
>Assign a single /64 encompassing all /128’s planned for loopback
>addressing schemes. Should I be using Unique Local addressing for
>loopbacks instead of going with a Globally routeable addressing scheme?
>Should each interface IP configuration have a /64 or a /128?

You can use ULAs for this; I know of a moderately sized network that does.
I think most people still use GUA. You’re not wrong either way, though I
know some people get emotional about ULA.

>
>Also when talking about CPE mgmt addresses what do you think is a
>practical way of going about assigning “Private” addressing schemes for
>cpe management purposes.

Reserve another block from your /32 and route it separately.
As somebody else said, if you find you’re running out of address space in
IPv6, there’s no shame in requesting more than a /32.

>
>I’m sure some of these questions will be answered when I dive deeper into
>how OSPFv6 works as well as BGP in regards to IPv6.

Maybe, but don’t panic. It’s not significantly harder in IPv6 than in
IPv4. 

>
>Are any of you currently running IPv6 and wished you had done something
>differently during the planning phase that may have prevented headaches
>down the road?

I always tell people: you’re going to rewrite your address plan three
times. Do what you can with it, then start deploying through the network.
You’ll see what changes you need to make once you know how your network is
unique.

I wish I’d pushed harder for /48s for customers from the beginning, even
though we would’ve needed more address space. I wish I’d started sooner,
but more than that I wish my vendors had started sooner, especially CPE
vendors.

I wish I had just replaced broken equipment rather than working around it.

I wish I had had better monitoring of both IPv4 and IPv6 specific systems,
so I could tell when one address family failed.

I wish I had been able to plan my transition technology earlier, so I
could move from dual-stack to IPv6.

Lee

>
>
>
>
>Kody Vicknair
>Network Engineer
>
>
>        [cid:imagebf3343.JPG at c9d2fbd2.4db10e0d] <http://www.rtconline.com>
>
>Tel:    985.536.1214
>Fax:    985.536.0300
>Email:  kvicknair at reservetele.com
>Web:    www.rtconline.com
>
>        Reserve Telecommunications
>100 RTC Dr
>Reserve, LA 70084
>
>
>
>
>
>Disclaimer:
>The information transmitted, including attachments, is intended only for
>the person(s) or entity to which it is addressed and may contain
>confidential and/or privileged material which should not disseminate,
>distribute or be copied. Please notify Kody Vicknair immediately by
>e-mail if you have received this e-mail by mistake and delete this e-mail
>from your system. E-mail transmission cannot be guaranteed to be secure
>or error-free as information could be intercepted, corrupted, lost,
>destroyed, arrive late or incomplete, or contain viruses. Kody Vicknair
>therefore does not accept liability for any errors or omissions in the
>contents of this message, which arise as a result of e-mail transmission.
>