/127 between routers?

[Benedikt Stockebrand]

Hello list,

just trying to catch up with the list, so I'll pick up a couple
subthreads simultaneously.


Sam Wilson <Sam.Wilson at ed.ac.uk> writes:

> - IPv6 allows arbitrary prefix lengths (RFC 4291 2.5 para 1)
> - IPv6 allows maximum 64-bit subnet prefix lengths in the currently
> allocated global unicast address space (RFC 4291 2.5.1 para 3)
> - current IPv6 implementations clearly do not enforce this restriction

That's not quite true.  RFC 4291, par's 2.5.4, 2.5.6, 2.5.7 and RFC
4193 par 3.1 also state that global, link-local, site-local and
unique-local unicast addresses have a fixed /64 subnet prefix.

Only unicast addresses from the ::/3 range (loopback, compatible and
mapped addresses) are currently defined to have different prefixes,
for more or less obvious reasons.

In summary, this means that IP stack implementations can't rely on a
fixed /64 boundary because future standards may come up with new
address ranges with semantics that require a non-/64 subnet prefix.
So stack implementations should be coded in a way that supports
non-/64 prefixes to avoid major rewrites and problems in the future.

But anything using addresses from the existing ranges may well assume
a /64 prefix in full compliance with the standards.


Pekka Savola <pekkas at netcore.fi> writes:

> If you're using SDH or other links where the link type is
> 'point-to-point' (in BSD/Linux 'ifconfig' sense, i.e., there is no
> neighbor discovery for link-layer address discovery), /127 is
> probably a good idea considering the tradeoffs.  In practise, nobody
> has implemented subnet-router anycast address mechanism that was a
> main reason for writing RFC3627.

Now I currently don't have a chance to test this (I'm revamping my
testbed right now), but unless I am completely mistaken then you can
configure point-to-point links between *arbitrary* addresses and don't
need any subnet prefix at all.

The RFCs I have seen so far largely ignore the existence of ptp links,
so in the long run this may not be exactly the least troublesome
approach.  (Pointers to RFCs I may have missed always and explicitly
welcome!)

If you really want to "save" addresses, you can do away entirely with
subnets on ptp links.  And yes, if I remember correctly this even
works with at least RIP and OSPF (I don't do EIGRP).


Mark Smith writes:

> Why doesn't anybody put a price on managing multiple prefix lengths?
> Maybe because they're so used to paying it with IPv4 that they don't
> recognise it as a cost?

This is the very key question to ask.

The answer, in numbers, depends on your particular environment, but
these are some items I'd enter into the calculation:

Cost of non-/64 subnet prefixes:

- Additional configuration effort.  (Preferably if you have to talk an
  amateur end user through it on the phone.)

- Additional troubleshooting effort during configuration.  (Again with
  the amateur end user at the other end of the line.)

- Additional problems caused by mismatching prefix configurations.
  (Guess who didn't configure his/her end of the link properly...)

- Additional complications when troubleshooting operational
  installations.  (...amateur...phone...)

- Extra effort if for some future reason all existing tunnels must be
  reconfigured to meet the standards.

Cost of /64 subnet prefixes:

- Additional addresses "wasted".

It's easy to put a price tag on the addresses "wasted" -- just check
what your upstream provider charges for extra addresses -- and it
should be an arbitrarily small \epsilon.  

The cost of non-/64 prefixes isn't easy to put into numbers, but even
if you don't care about probability theory or risk analysis at all it
should be obvious that it is anything but negligible.


And how "wasteful" are /64 subnets on ptp links?  Again this depends
on your particular setup, but here are at least two common scenarios:

- If you have a leaf site with a /48 global routing prefix, split it
  into chunks of /56 or so for individual departments, floors,
  buildings or whatever to limit the routing table entries in your
  company backbone to a reasonable value.  Set aside one /56 for ptp
  links (so you only need a single ACL/packet filter rule for all of
  them). That'll "waste" 256 of your precious 64k subnets, or 0.39%,
  but if you really run out of subnets this way, then your ISP will in
  all likelyhood provide you with another /48.

- If you are a leaf ISP with a /32, first split it in /48s for your
  customers.  Guess how many ptp links per per customer you need on
  the average and allocate one /48 per average ptp link per customer.
  If you need a single link per customer, that'd take a full /48, or
  1/65536, or 0.0015% of your address space, for ptp links.

So in both scenarios this seems a rather marginal "loss".  Of course
there may be other scenarios where the waste of addresses is
significant, but I have never personally seen one.

So considering the additional trouble, and with the environments I've
seen so far in mind, I'd suggest to always go either with a /64 subnet
prefix or arbitrary addresses on any ptp link.


Have a nice weekend everybody,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.