/127 between routers?

[Mark Smith]

On Wed, 13 Jan 2010 10:02:18 -0500
Tim Durack <tdurack at gmail.com> wrote:

> On Mon, Jan 11, 2010 at 2:55 PM,  <sthaug at nethelp.no> wrote:
> >> The opposite was indicated to me by Cisco; that on the CRS-1 masks > 64
> >> bits would slow the pps throughput of the ASIC. That statement would in
> >> turn affect loopbacks, too... no more /128s? Meanwhile, 7600s were
> >> explicitly mentioned as not being affected in this same way.
> >
> > I would definitely be sceptical of any such CRS-1 claims until some
> > supporting evidence can be produced.
> >
> >> I think if you use anything other than /64s, there will be bumps on the
> >> road ahead for you.
> >
> > That train left the station long ago.
> >
> > Steinar Haug, Nethelp consulting, sthaug at nethelp.no
> >
> 
> This thread has definitely provided food for thought.
> 
> We have currently deployed /128s on loopbacks, and /112s on ptp,
> assigned from a site infrastructure /48. /64s are used on everything
> else, assigned from a per-site "customer" /48. That maintains a clean
> separation between infrastructure and customer space, something that
> has been sorely missing from our IPv4 deployments.
> 
> The ARIN wiki (http://www.getipv6.info/index.php/IPv6_Addressing_Plans)
> encourages this kind of address plan.
> 

It's a shame that that document doesn't provide a link to "RFC4291
- IP Version 6 Addressing Architecture", or any of it's ancestors
(RFC3513, RFC2373, RFC1884) . I think it should be referencing them,
stating what the official IPv6 addressing architecture model is, and
stating why it is recommending differently to it. It should also
provide a link to "RFC5375 - IPv6 Unicast Address Assignment
Considerations".

> rfc4291 is quite clear that only /64s should be used on interfaces.
> rfc3627 acknowledges the operational reality that other lengths can
> and are being used on ptp interfaces (/127, /126, /120, /112.)
> 

Sure it acknowledges them, but it doesn't support using them - it's
title is - "/127 Prefix Length Considered Harmful". Section 4,
"Solutions", provides a list of solutions, with the first being

"1. One could use /64 for subnets, including point-to-point links."

it then lists an order of recommended solutions, with 

"1) is definitely the best solution, wherever it is possible."

Section 5, "Other Problems with Long Prefixes" discusses problems of
using non-/64 lengths other than /127s.


> That leaves me in a state of confusion.
> 
> I could assign /64s per ptp without difficulty. Should I also assign
> /64s per loopback? Should I really being using some form of EUI-64 for
> these addresses, to guarantee the interface ID is unique no matter
> what the network prefix? What happens when I replace hardware and
> EUI-64 changes ptp/loopback addresses?
> 


"RFC5375 - IPv6 Unicast Address Assignment Considerations" discusses
these sorts of issues.


> I'm sure others have gone through this same mental (and design/ops) exercise.
> 

It seems to me that what this really is about is trying to be in the
best position, or actually, since "best position" is subjective, the
least costly (in time and therefore usually financial) position in the
future. It's about trying to avoid unexpected and future
renumbering/change of prefix length costs. 

The 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, 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 fundamental and
authoritative design documents for IPv6 (i.e. the RFCs, not
books, wiki-pages or vendor recommendations - they are all derived or
should be derived from the RFCs), 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. 


I see IPv6 as an exercise in both fundamentally overcoming the
constraints of IPv4, but also achieving or better yet, exceeding the
operational simplicity and convenience of more modern protocols than
IPv4, such as Novell's IPX and Appletalk. If IPv6 fails to meet that
simplicity and convenience, then I think the effort of developing and
deploying it would have failed. As how IPv6 is deployed significantly
contributes to how well it meets these goals, I think it is important
to avoid redeploying IPv4 methods and models that just aren't necessary
anymore, and who's driving needs (i.e. lack of address space) have been
specifically designed out of IPv6.


Regards,
Mark.