/127 between routers?

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Mon Jan 11 12:56:50 CET 2010


Since I'm quoted,

On Mon, 11 Jan 2010 10:12:55 +0100
Xavier Beaudouin <kiwi at oav.net> wrote:

> Hi there,
> 
> Since I am the one that started this thread, I wanted to clarify why I am
> asking that.
> 
> First, I wanted to quote Mark :
> 
> On Sat, 9 Jan 2010 12:51:28 +1030, Mark Smith
> 
> [...]
> 
> > What do they say? "Those who ignore history are doomed to repeat it."
> > 
> > Sometimes you need to make design decisions based on not so much the
> > likelyhood of an event happening, but what the consequences are if it
> > does. So you're probably right, a "hard classful" addressing structure
> > in 128 or 256 bit IPv6 addresses probably wouldn't encounter any future
> > issues - but dealing with the consequences if it does are likely to be
> > near impossible. It's better to be safe than sorry.
> 

You're taking my quote out of context, and I think you might have
missed my point. I was *only* commenting on why I thought there
was soft rather than hard boundaries between the network and node
portion i.e. classless. The cost of going from classful to classless
addressing in the mid 90s was software / hardware upgrades to all
routers in the Internet. I think the possibility of ever doing
that anywhere near as successfully in the future as it was done in the
past is very unlikely. 

> I agree with Mark, we have for now "plenty" of address space, but really,
> I don't want to make same error than we all did on IPv4.
> 

Ever calculated what 2^96 is? That is how much bigger the IPv6 address
space is over IPv4. In no way was I saying that we should be
conservative with IPv6 address space and use > /64 prefixes for node
addresses. Initially I suggested that I was considering /128s for
loopbacks, but after thinking more about it because of this thread,
I've changed my mind. /64s everywhere is the simple, convenient, and
IPv6 Addressing Architecture compliant addressing model.

> Even with a /40 or /48 (that I have for my non profit organization), we
> have lots of space, the core network I currently use has lots of point to
> point interconnections. On IPv4, we can do that with /30 or even with Cisco
> for example /31 (that, I assume very rare).
> 
> Now all my routing stuff is done by software, not for the cost, but for
> the flexibility and also to provide my organization the possibility to give
> some good stuff and be "vendor" free. Avoiding bug, race and so on (yeah
> there is fscking bugs also on free/opensource solution I agree !).
> 
> Now with a single /48, we can have 65535 /64.
> This is quite large... I know, but using a /64 for only 2 ip address, is,
> I think a big waste of ressources...
> 

I don't agree at all. "waste" is something that occurs when you use
a resource without getting some value for it. If you get useful value
from something when you use it, by definition you're not wasting it. If
you use something unnecessarily, only then are you wasting it.

You're not wasting IPv6 address space by using a /64 on a
point-to-point link if the value you are getting (which you can't get in
IPv4) is *simplicity* and *convenience*. I want the simplicity and
convenience of Novell's IPX addressing, like I had in the early 90s,
before I dealt with IPv4. I want to spend my limited brain power on
real problems, not ones that are artificially created by by not
following the IPv6 addressing model, and having to make sure I always
get the prefix length right. I don't want to have to worry about the
values of bits 70 and 71 in the IPv6 address because I've made them
part of the network, rather than the node portion of the address.

I'm happy with address space "waste" - I've been "wasting" Ethernet
addresses for decades. I don't need 46 bits of Ethernet address space
for Ethernet to work. Most Ethernets would only need about 10 bit
addresses, supporting 1024 devices. I only need 48 bit addresses for
the *simplicity* and *convenience* of not having to configure unique
addresses into the card. Think the idea of plug-and-play was invented
in the early 90s? Ethernet had it since 1980, because those extra 32 or
so bits made Ethernet addresses world wide unique - and that's simple
and convenient.

I've even thrown away network cards, and those MAC addresses will
never, ever, ever be used again! That felt like "waste", but then I
thought, "bah, I'm being silly, there's still tons of them left.
They're not even worth my time writing them down to use in the future."

> I agree also that some TCAM / Hardware don't like prefix > /64. I noticed
> that. So if I will use some hardware vendor thing, I will use /64 in case
> to avoid software routing (in this case, I can be LIR, so a /32 will be
> given to me).
> 
> Also use /127 or /126 between routers, is a good responsibility for all
> IPv6 operators. Avoiding asking for to much prefixes in RIPE/ARIN/... is a
> good way to be a good citizen...
> 

I don't think you're being a good citizen, nor are you looking after
your network's owners and end-users if you don't follow the RFCs.

> To get some conclusion within this thread :
> 
> - if you use hardware that route that (switch/router): a /64 should be
> used and will get good performance
> - if you use software routers, you can use whatever you want : /64, /112,
> /120, /126 and sometime /127 (but not recommended on Ethernet)
> - if you use loopback, you can use /64 or /128 (depending if you use
> hardware or software routers)
> - if you need RA, you *have to* use /64
> 

I only support a part of one these recommendations -
"you *have to* use /64", because that's what the RFCs say, and that's
what future RFCs will assume. If far safer to follow them - there's less
likely to be unexpected consequences, which may cause you to have to
renumber to /64s anyway - and I hope you don't have to do it in a hurry
because you're network is suffering from an outage because of those
unexpected consequences.

Sorry if my above sounds like rant, but I want to make absolutely sure
people don't think I support these conclusions.

Regards,
Mark.


More information about the ipv6-ops mailing list