IPv6 Loopback/Point-to-Point address allocation

Mailman List Mirror (Read Only)
1

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.

I’ve read recent BCOP drafts that have been approved by the IETF:
https://www.ripe.net/publications/docs/ripe-554
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?

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?

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.

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.

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?

Kody Vicknair
Network Engineer

        [cid:imagebf3343.JPG@c9d2fbd2.4db10e0d] <http://www.rtconline.com>

Tel: 985.536.1214
Fax: 985.536.0300
Email: kvicknair@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.

2

You want to configure point to point interfaces as /127 or /126 even if you
allocate a full /64 for the link. This prevents an NDP exhaustion attack
with no downside.

Loopback interfaces should be configured as /128. How you allocate these do
not matter.

3

I don't see any point of using larger Network space for point to point
links or on loopback addresses. To me the best is that 127-Bit prefixes on
IPv6 point-to-point links and /128 on Loopback serves the purpose, and
offers us a lot of advantages such as it prevents us from neighbor
discovery exhaustion attack (rfc6583)

Draft is mainly referring to end user WAN links (i.e. xDSL, Cable, FTTN/H)
and that's a different story where /64 /56 /48 are still open to dispute :stuck_out_tongue:

4

Baldur Norddahl wrote:

Loopback interfaces should be configured as /128. How you allocate these do
not matter.

..so long as there are interface ACLs on your network edge which block
direct IP access to these IP addresses.

Nick

5

Hi,

6

Hi,

> Baldur Norddahl wrote:
> > Loopback interfaces should be configured as /128. How you allocate these do
> > not matter.
>
> ..so long as there are interface ACLs on your network edge which block
> direct IP access to these IP addresses.

or, maybe even more efficient, assign all loopbacks from a dedicated
netblock which you null-route on the edge/your border devices.

Null-routing may not be sufficient, if the edge/border router has a
route to that /128; the (forwardable) /128 entry will win from the
blackholed /64 FIB entry since it is more-specific. Applying an ingress
interface ACL to each and every external facing interface will probably
work best in the most common deployment scenarios.

For router-to-router linknets I recommend to configure a linknet that is
as small as possible and is supported by all sides: /127, /126, /120,
etc. Some vendors have put in effort to mitigate the problems related to
Neighbor Discovery Protocol cache exhaustion attacks, but the fact of
the matter is that on small subnets like a /127, /126 or /120 such
attacks simply are non-existent.

Kind regards,

Job

7

An alternative is to just have link-local addresses on your point-to-
point links. At least on your internal links where you run your IGP.
On external links, where you run eBGP or static routes, it's probably
more trouble than it is worth, though, since link-local addresses can
change if you replace the hardware, requiring a config change on the
other end. (Also, I'm not sure all BGP implementations support using
link-local addresses.)

  /Bellman

8

This is solvable problem. Vendors support 'bgp listen' or 'bgp allow'
to accept BGP session from specific CIDR range. Similarly you could
allow IPv6 on interface, with SADDR anywhere in link-local. Your own
end link-local stability you could guarantee by manually configuring
MAC address, instead of using BIA. I.e. customers would experience
stable DADDR, but we wouldn't care about customer's SADDR.

However I don't think market would generally appreciate the
implications linklocal brings to traceroute, where least bad option
would be just to originate hop-limit exceeded from loop0, with no
visibility on actual interface.

9

Hi,

> An alternative is to just have link-local addresses on your point-to-
> point links. At least on your internal links where you run your IGP.
> On external links, where you run eBGP or static routes, it's probably
> more trouble than it is worth, though, since link-local addresses can
> change if you replace the hardware, requiring a config change on the
> other end. (Also, I'm not sure all BGP implementations support using
> link-local addresses.)

all BGP implementations I'm aware of do that (support LLAs), BUT at least Cisco's doesn't support using the same LLAs in multiple BGP sessions (e.g. on PE-CE links) which in turn ruins the potential benefits in many environments, see

This is solvable problem. Vendors support 'bgp listen' or 'bgp allow'
to accept BGP session from specific CIDR range. Similarly you could
allow IPv6 on interface, with SADDR anywhere in link-local. Your own
end link-local stability you could guarantee by manually configuring
MAC address, instead of using BIA. I.e. customers would experience
stable DADDR, but we wouldn't care about customer's SADDR.

However I don't think market would generally appreciate the
implications linklocal brings to traceroute, where least bad option
would be just to originate hop-limit exceeded from loop0, with no
visibility on actual interface.

some might be willing to accept that, as a trade-off for other benefits operations-wise.

best

Enno

10

Hi,

Hi,

> > Baldur Norddahl wrote:
> > > Loopback interfaces should be configured as /128. How you allocate these do
> > > not matter.
> >
> > ..so long as there are interface ACLs on your network edge which block
> > direct IP access to these IP addresses.
>
> or, maybe even more efficient, assign all loopbacks from a dedicated
> netblock which you null-route on the edge/your border devices.

Null-routing may not be sufficient, if the edge/border router has a
route to that /128

good point.
I was coming from an Enterprise network perspective where
- the border devices do not necessarily hold the/those 128(s) given there's a layer of stateful firewalls in between which creates an isolation boundary for routing protocols.
- people do not necessarily fully trust the (outsourced) entities responsible for implementing the filters/ACLs.
- this is hence a not-uncommon strategy to feel/be safer as for the (unwanted) global reachability of loopbacks, after the introduction of IPv6.

best

Enno

; the (forwardable) /128 entry will win from the

11

Hi,

Hi,

> > Baldur Norddahl wrote:
> > > Loopback interfaces should be configured as /128. How you allocate these do
> > > not matter.
> >
> > ..so long as there are interface ACLs on your network edge which block
> > direct IP access to these IP addresses.
>
> or, maybe even more efficient, assign all loopbacks from a dedicated
> netblock which you null-route on the edge/your border devices.

Null-routing may not be sufficient, if the edge/border router has a
route to that /128; the (forwardable) /128 entry will win from the
blackholed /64 FIB entry since it is more-specific.

just thought about it a bit.
As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)?
Am I missing sth here?

thanks

Enno

Applying an ingress

12

> Null-routing may not be sufficient, if the edge/border router has a
> route to that /128; the (forwardable) /128 entry will win from the
> blackholed /64 FIB entry since it is more-specific.

just thought about it a bit.
As mentioned (in other post) I was thinking of a specific use case/setting, but wouldn't a static null-route (of a blackholed /64) win over a /128 learned from a RP anyway (given the better AD)?
Am I missing sth here?

Longest prefix match wins.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

13

rfc5837 would help but it seems market universally ignore it for some reason unknown to me (lack of interest and IPv6 adoption?)

We find LL is simpler, operation wise at some cases.

14

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, please. If it turns out a /32 isn’t enough space to do this, then a /32 is too small for your network and you should trade it for a larger block.

I’ve read recent BCOP drafts that have been approved by the IETF:
https://www.ripe.net/publications/docs/ripe-554
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 and no. An IX is usually _NOT_ a point to point, but a layer 2 fabric much like a LAN except that it connects a bunch of different ASNs.

Still assigning a /64 to point to points makes a lot of sense, even if you use them as /127s on the link.

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?

I prefer GUA. These might show up in traceroutes.

Each LO interface should have a /128. There’s no point (in most situations) in giving anything more).

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.

That’s way too open ended to provide useful advice. It really depends on your particular situation, topology, political limitations, and more.

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.

99.9% they work just like 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?

Sounds like you’re generally on the right track. You may want to look in the archives for the NANOG on the Road in Las Vegas. I gave an Address Planning talk there and the slides should be online. If you’re anywhere near Cambridge, MA Thursday, I’ll be doing it again there.

Owen

15

How’s that work out for you on routers with the same MAC address on multiple interfaces when you’re trying to troubleshoot ECMP trace routes?

Owen

16

On 9/9/17, 12:06 PM, "NANOG on behalf of Kody Vicknair"

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

17

Also write your iACL/edge-filter before you deploy your IPv6. If you
can't write concise, almost static IPv6 iACL, your numbering plan
requires work.

18

It _MIGHT_ help in some circumstances if it were ubiquitously or universally implemented, however, as you yourself noted, it is not.

You were offering advice to someone without investigating the characteristics of his network. That advice could well have negative tradeoffs which you neglected to mention. I felt a duty to point them out.

Owen