Using /126 for IPv6 router links

Mailman List Mirror (Read Only)
1

Hi

In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.

I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.

So what do you think? Good? Bad? Ugly? /127 ? :wink:

Cheers

Mathias Seiler

MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
T +41 61 201 30 90, F +41 61 201 30 99

mathias.seiler@mironet.ch
www.mironet.ch

2

This thread:

http://www.gossamer-threads.com/lists/nsp/ipv6/20788

had a long discussion regarding this topic.

3

A couple of points for thought:

1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big.

2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes.

4

> http://www.gossamer-threads.com/lists/nsp/ipv6/20788

A couple of points for thought:

1. Yes, the IPv6 address space is unimaginably huge.
Even so, when every molecule in every soda can in the world has its own
IPv6 address in years to come, it might not seem so big.

We'd better start worrying about conserving Ethernet addresses then,
because they're going to run out way before IPv6 ones will.

First thing we'll need to do is setup a registry so that when ever
somebody throws out an Ethernet card, they write down the MAC address
so that somebody else can recycle it. Secondly we'll need to get the
IEEE specs changed so that any point-to-point ethernet links don't
use addressing - we're wasting two addresses on each one of them.
We'll also save bandwidth by not sending an extra 12 addressing bytes
in each frame on 10Gbps or 40/100 Gbps links in the future.

2. A more immediate concern with using things like /64s or whatever on p2p links is inadvertently turning routers into sinkholes.

That's a new bit of FUD. References?

5

It isn't 'FUD'.

redistribute connected.

6

"We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil" --Donald Knuth

A couple of points for thought:
1. Yes, the IPv6 address space is unimaginably huge. Even so, when every molecule in every soda can in the world has its own IPv6 address in years to come, it might not seem so big.

Then obviously, it's giving every molecule in every soda can an IP
address that is the waste that matters. There are several orders of
magnitude between the number of molecules in a soda can (~65000 times
as many) as the number of additional IPs used by giving a
point-to-point link a /64.

When comparing the number of molecules in a soda can TO 2^64.
It's like in the IPv4 world comparing a /30 to a /31. And
arguing it's wasteful to give a point-to-point link a /30 since
all it needs (in theory) is a /31. Near the beginning of IPv4
(before exhaustion was an issue). when at the same time standard
practice was allocating /13s to users who will use at most a /20
in 10 years.

Optimizing this early creates potential issues and reduces flexibility
going forward.

The designer/operator should not confuse design patterns that use more
IP addresses than the minimum technically possible, for a block of
addresses, with design selections that are gross wastes of address
space -- such as assigning every molecule its own IP.

IPv6 is a very large address space, so it's LARGE optimizations
that matter, such as not giving every molecule its own IP. Not
small optimizations that matter, such as using a /126 for a
relatively small number of P-t-P links (in the grand scheme of
things) versus a /64.

Anyways, I would suggest reserving a /64 to each P-t-P link, and
(If you prefer) set static neighbor entry for the peer (in the case
of Ethernet) and configuring a /72 (smaller than what you have
reserved). For the sole reason of disabling IPv6 autoconfig
and neighbor discovery.

Technically everything to the right of the /64 boundary is reserved
for the HOST portion, and such is the design of IPv6.

This allows for greater scalability than assigning a longer prefix.
If that specific connection is ever to be replaced one day with a
link that's _not_ point-to-point, or to be expanded, then the
designer has greater flexibility: an option that does not require
re-numbering the changed link.

7

I'm not too sure of the math behind this - and it was just one example. The gazillions of one-time-use nanomachines used to scrape away plaque in just a single patient's bloodstream, et. al., argue against needless consumption of IP addresses, IMHO. Not to mention all the smart material molecules continuously communicating with one another via NFC or somesuch in order to dynamically re-shape automobile aerodynamics and so forth.

Of course, the sinkhole issue is of far greater immediate concern.

8

<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>

(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)

why not just ping your vendors to support this, and perhaps chime in
on v6ops about wanting to do something sane with ptp link addressing?
:slight_smile:

-Chris

9

a kind soul or 2 asked: "How do I sign up for the v6ops mailing list?"
(it's actually the ipv6 wg mailing list)
<https://www.ietf.org/mailman/listinfo/ipv6>

should get you there...

-Chris

10

> That's a new bit of FUD. References?

It isn't 'FUD'.

redistribute connected.

In my opinion it's better not to do blind redistribution. More control
means less things that are unexpected or or can be forgotten.

That being said, I don't understand why that's a problem, and why that
problem doesn't already exist in IPv4.

11

> Hi
>
> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
>
> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
>
> So what do you think? Good? Bad? Ugly? /127 ? :wink:

<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>

(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)

<cough>Internet Draft</cough>

No disrespect to the people who've written it, however it's a draft at
this point, not an RFC.

The current IP Version 6 Addressing Architecture RFC (RFC4291) says,

" For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format"

If that draft is going to go anywhere, then I would expect there also
needs to be a new version of RFC4291.

12

> Hi
>
> In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.
>
> I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.
>
> So what do you think? Good? Bad? Ugly? /127 ? :wink:

<cough>draft-kohno-ipv6-prefixlen-p2p-00.txt</cough>

(<http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt>)

<cough>Internet Draft</cough>

No disrespect to the people who've written it, however it's a draft at
this point, not an RFC.

absolutely. so... if it's of interest, speak up (on the v6 wg mailing
list) or let the authors know.

The current IP Version 6 Addressing Architecture RFC (RFC4291) says,

" For all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format"

If that draft is going to go anywhere, then I would expect there also
needs to be a new version of RFC4291.

I believe the authors know this as well.

-Chris

13

Hi

In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard.

I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.

So what do you think? Good? Bad? Ugly? /127 ? :wink:

Use the /64... It's OK... IPv6 was designed with that in mind.

64 bits is enough networks that if each network was an almond M&M, you would be able to fill all of the
great lakes with M&Ms before you ran out of /64s.

Owen

14

It isn't 'FUD'.
redistribute connected.

In that case, the fault would lie just as much with the unconditional
redistribution policy, as the addressing scheme, which is error-prone
in and of itself.

No matter how you address your links or what type of equipment on your
network, it's probably possible to find some configuration error that
will produce poor router behavior.

...

I'm not too sure of the math behind this - and it was just one example. The
gazillions of one-time-use nanomachines used to scrape away plaque in just a
single patient's bloodstream, et. al., argue against needless consumption of IP
addresses, IMHO. Not to mention all the smart material molecules continuously

The trouble is both of the examples, is they both imply something far
greater than mere needless consumption of IP addresses in and of
themselves. Assigning global IP addresses to individual
nanonites is a massive waste in and of itself.

It is easy to logically reject needlessly assigning each nanonite as
an IP address, because they are obviously too massive in number to
easily achieve a sane addressing scheme. My point is that in the
face of such massive waste, the smaller amounts of "needless
consumption" become irrelevent.

If you are justifying consuming 2*10**25 IP addresses on
one-time-use nanonites, you can certainly spend 5% of your IPv6
address space on point-to-point links without the P-t-P links
being the issue.
5% would be >100,000 P-t-P links in that case.

Either way, one /43 would easily provide more than enough IPs
for both nanonites and 100,000 /64 p-t-p links. And with a standard
/40 subnet, you'd have 4 additional bits left over to work with,
to sanely subnet your nanonites.

The issue in scenarios like that one is the things there are a lot of
that _consume_ many addresses.

Point-to-point addresses are rare, much rarer than hosts, and much
less massive in number than nanonites addressed onto a LAN would be,
so giving a P-t-P link an an entire /64 should not be a
consumption issue in any conceivable (likely) scenario, where a
proper amount of IPv6 space has been obtained in the first place.

15

Did somebody once say something like that about Class C addresses?

16

Sometimes good enough > perfect

Never know what is going to come along to turn your addressing plan on its head.

-brandon

17

Sometimes good enough > perfect

Never know what is going to come along to turn your addressing plan on its head.

It seems to me that what this really is about is trying to be in the
best position in the future. I think mainly it's about trying to avoid
unexpected and future renumbering/change of prefix length costs.

Possible positions or situations are :

1. you use a variety of node address lengths across your network, and
there are no future consequences - everything works and continues to
work

2. you use a single node address length (i.e. /64) across your network,
and there are no future consequences - everything works and continues
to work

3. you use a variety of node address lengths, and you'll have to
renumber to /64s, because you encounter unacceptable issues e.g.
device performance issues, inability to use features you'd find useful
e.g. SEND.

4. you use a single node address length, and you'll have to move to
variable length node addresses, because the IPv6 address space ends up
not being as big as it was designed and calculated to be.

Ideally, situations one 1. or 2. will occur, as they're the least
costly. 1. is both initially and operationally slightly more costly than
2. as you'll also have to also accurately manage prefix lengths, and
consider and/or address other non-/64 issues identified in RFC3627,
which I think makes 2. the better choice.

The question is, which of those two has the least risk of
devolving into the corresponding 3. or 4? As the addressing
architecture documents for IPv6 currently state that for other than
addresses that start with binary 000, the interface ID are required to
be 64 bits in length, it seems to me that situation 2. is the least
risky and least likely to devolve into situation 4. Vendors/developers
using RFCs as authoritative IPV6 documents are going to assume /64s, as
are future protocol developers.

18

That's why we have the safety valve...

2000::/3 is the total address space being issued currently.
So, if we discover that there aren't enough /64s like we currently
think there are, then, before we start issuing from 4000::/3, we
can have a new address plan for that address space while leaving
the 2000::/3 in it's current state of 1, or, ideally, 2.

Owen

19

Of course--I was asking about the metaphorical message implying "More than we can imagine ever needing".

I remember a day when 18 was the largest number of computers that would ever be needed.

20

In a message written on Sat, Jan 23, 2010 at 01:52:21PM +0100, Mathias Seiler wrote:

I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong.

So what do you think? Good? Bad? Ugly? /127 ? :wink:

I have used /126's, /127's, and others, based on peers preference.

I personally have a fondness for /112's, as it gives you more than
2 addresses, and a DNS bit boundary.

For all the pontification about how there are enough /64's to number
all the grains of sand, or other nonsense, I think that ignores too
much operational information.

rDNS is important, and becomes harder in IPv6. Making it easier
is importnat.

Having a scan of a /64 fill your P2P T1 is poor design, all because
you assigned 2^64 addresses to a link that will never have more
than 2 functional devices.

Most importantly, we should not let any vendor code any of these
into software or silicon, in case we need to change later.