/127 between routers?

[Mark Smith]

On Thu, 7 Jan 2010 11:25:23 +0000
Sam Wilson <Sam.Wilson at ed.ac.uk> wrote:

> 
> On 5 Jan 2010, at 21:50, Mark Smith wrote:
> 
> > On Tue, 5 Jan 2010 20:26:55 +0100
> > Gert Doering <gert at space.net> wrote:
> >
> >> Hi,
> >>
> >> On Tue, Jan 05, 2010 at 08:59:58AM -0800, Michael K. Smith -  
> >> Adhost wrote:
> >>> We use /64's for interfaces/interface sets/ and route /48's  
> >>> through and
> >>> to those interfaces.  [..]
> >>> Granted, I do use /128's for loopback addresses.
> >>
> >> Same here.  For similar reasons.  Eventually, CGAs and SEND might  
> >> show
> >> up, and then I might want /64s - and since a single /48 will be  
> >> sufficient
> >> to number all routers we'll ever have, I stopped doing my IPv4  
> >> worries
> >> ("oh, this is all so wasteful") here.
> >>
> >> I wouldn't want to enter a religious war here, though.  /64s might be
> >> useful one day, or might be not.  /120 and /112 work as well.  So  
> >> pick
> >> something you're comfortable with.
> >>
> >
> > 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?
> >
> > I'm for 'less is more'. /64s everywhere is less complexity and with
> > a /48 as an individual/end-site, you get 65536 of them. As an ISP with
> > a /32 you get 65K /48s, and if you use four of those for your own
> > internal addressing you'll have 256K /64s - how many ISPs have that
> > many internal point-to-point or otherwise links and loopbacks?
> >
> > Why be conservative when the corresponding cost is to to record,
> > maintain and constantly have to work with and get right, differing
> > prefix lengths? If it's a /64 or nothing, you can never get it wrong.
> 
> Let me delurk and offer the following:
> 
> - IPv6 allows arbitrary prefix lengths (RFC 4291 2.5 para 1)

History has shown that creating hard boundaries between the network and
node portion (i.e. Classful addressing) may reduce forwarding
system flexibility and require mass software/hardware upgrades. I think
the lesson learned from the Classful to CIDR transition in the mid 90s
was to avoid any structure in addressing, and make forwarding
decisions using a separate prefix length value. Fortunately it was
feasible at that time to perform software upgrades (did IPv4 hardware
forwarding exist?) to the routers in the Internet to change the way
they performed address lookups in route tables.

> - IPv6 allows maximum 64-bit subnet prefix lengths in the currently  
> allocated global unicast address space (RFC 4291 2.5.1 para 3)

History shows that humans deal best with simplicity. To my
knowledge, all major protocols (IPv4 (RFC760, "Addressing", or
Internet Engineering Note 5 (in the ien subdirectory of an RFC archive),
4.3.2), IPX, Appletalk, DECNet), except CLNS (from what I understand, a
copy of IPv4 at the time with some "necessary improvements"), have
initially been designed with a simple fixed length node address, and a
fixed length network address.

> - current IPv6 implementations clearly do not enforce this restriction
> 

If you combine the desirable properties of both forwarding based on an
arbitrary number of significant bits, and a simple fixed length node
address, I think you end up with IPv6 as we have it today. The reason
why IPv6 implementations don't strictly enforce the /64 boundary at
the forwarding level is because it is a soft boundary - this will
avoid wide scale and probably now impossible software upgrades or
hardware replacements to change the forwarding method used for IPv6.
I'm of the opinion that one of the reasons that there is only a single,
fixed node address (soft) boundary is that operational simplicity has
value, and if you can afford it, you should have it. Those of us who've
worked with protocols other than IPv4, such as Novell's IPX or
Appletalk, will have experienced that simplicity. Since that /64
boundary was decided, other value has come out of that single and large
node portion e.g. SEND. 

> The second bullet point above seems to reflect the 8+8 architecture  
> proposed by Mike O'Dell [1] or the network+host architecture of  
> Novell IPX and the like.  Part of O'Dell's argument was that routing  
> kit should be optimised for making routing decisions only on the  
> upper 64 bits of an address.  What worries me in Mark's proposal (if  
> it's that not inflating the strength of what he's saying) is that we  
> might end up with 8+8 by stealth - CPE which only recognises 64-bit  
> prefixes, big-iron routers that route 64-bit prefixes in the fast  
> path and relegate anything longer to slower processing.  It feels as  
> though someone should be deciding either that subnet prefixes should  
> never be longer than 64 bits or championing the right for prefixes to  
> be any old length you want.
> 

Somebody has decided that the subnet prefix length should never be
longer than 64 bits - it's stated in RFC4291, "IPv6 Addressing
Architecture"

"  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."

> > Personally I'm considering a slight exception to the above by
> > using /128s on router etc. loopbacks, however that is for the
> > convenience of being able to see device IPv6 addresses/IDs by  
> > filtering
> > route table output e.g. "show ipv6 route | inc /128". That's a  
> > doubling
> > of the addressing management cost over just using /64s everywhere,
> > which is why I'm still debating it a bit
> 
> The same argument applies to management systems - what happens when  
> the only systems available assume that the longest subnet prefixes  
> is /64 because that's what's currently in use (RFC 4291 2.5 vs  
> 2.5.1)?  What about staff training?
> 

I find that argument a bit hard to swallow. Surely you're not saying
that the only reason why we can't have the simplicity and other
benefits of a single fixed length node address is so that network
management systems don't build in a maximum prefix length assumption,
even though the current RFCs say that this is an assumption that can be
made?

The only reason I'm wavering on using /128s on OAM loopbacks is
because there'll only ever be one "node" on that virtual network, and I
don't think I'd ever need any of the features that can take advantage
of 64 bit fixed length node addresses. But probably I shouldn't make
that assumption, as it's less future proof than always using /64s. If I
had 10 000 routers, and used /64s on each of their OAM loopbacks, with
20 000 or so links between them, I've still got 30 000 /64s left out of
a /48. Why am I bothering to be so unnecessarily conservative? (and
I've probably just made my mind up on that one - there's more
operational safety in following the IPv6 addressing models described in
the RFCs. Future RFCs, which may add features I'll find useful, will
be assuming those previously specified addressing models.)

> > I think the key realisation I've come to with IPv6 is that you get
> > enough address space that you don't just have to worrying about
> > allocating it out to make things work, you can allocate it out to also
> > make addressing *convenient* to work with, with as simple as possible
> > usually also being most convenient. Addressing convenience isn't a
> > property we've had with IPv4 for a long time (e.g. slicing up a  
> > Class B
> > at the 3/4th octets, using the 3rd octet as subnet numbers). With IPv6
> > we get it back, and we get more of it than we ever had with IPv4.
> 
> I (FWIW) think the key realisation with IPv6 is that we have too many  
> bits available and don't really know what to do with them.  :-)
> 

I think we'll use them for operational simplicity and convenience, and
fancy things like SEND and CGA, similar to how we've used the extra 32
or so operationally unnecessary bits in Ethernet addresses for the last
20 or so years.

Regards,
Mark.