RE: Review of draft-ietf-v6ops-nap-02.txt

["Anssi Porttikivi" <Anssi@teleware.fi>]

About the number of IPv6 addressable objects: 

The global carrier prefixes are now /35. I guess we expect to always have less of them than the current ~180 000 IPv4 global routes. Within one carrier prefix we currently have 2^(48-35) = 2^13 = 8 K end customer organization networks at most, because the customer prefix is 48, currently always. And within a customer, we have 2^(64-48) = 2^16 = 64 K subnets maximum. And like Mr. Huitema pointed, subnet sizes are determined by the link layer technology. So an estimate for a maximum number of global hosts with the current systems is:

  (100 K operator prefixes) x (8 K customer organization) x (64 K subnets) x
  (10 K hosts in a maximal near-future link network)
   = 512 x K^4 ~ 10^15.

Of course we can change the system radically. My favourite would be to implement UUCP/9P like source routing by embedding local node numbers in 128 bits: like "2!23!234!145!143!34!3!6". This fits easily to 128 bits with some nice coding, like fixed 8 bits per hop. Old tricks like "path alias" databases can provide optimization. We could have a global/country-specific "well-known" nodes so you could use addresses like usa!125!221!23!6, and your path alias system would expand that to a full route. 

After all, Internet was supposed to push the intelligence to the edges, and remove "faith sharing" and need for complex and coherent standards in networks. So why not take the routing out of the networks and put it to the end nodes? Some may argue that carriers don't want the customer to control the routing. But a carrier does what the customer pays for. If a customer does not want to pay for routing, but wants to do his own routing, there should be a business case. Note that with source routing networks you can also offer simple, differently priced QoS links as building blocks for customers, and let them implement the QoS they desire.

Well, then again, let's just migrate all applications to 9P. That's the beautiful Plan 9 OS socket like abstraction (now supported by Linux kernel also), which can use TCP/IP or other less intrusive lower layers (IL/IP, anything), and which can use source routed connections over dissimilar networks, and which includes a beautiful general security model. 

Yours,
Anssi
app@iki.fi
Instructor
Teleware Finland

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Christian Huitema
Sent: 1. kesäkuuta 2006 10:24
To: David Conrad; Fred Baker
Cc: Thomas Narten; Jim Bound; Tony Hain; Brian E Carpenter; EricLKlein; gunter@cisco.com; Ralph Droms; v6ops@ops.ietf.org; Lindqvist Erik Kurt; Margaret Wasserman
Subject: RE: Review of draft-ietf-v6ops-nap-02.txt

> On May 31, 2006, at 8:48 AM, Fred Baker wrote:
> > Yes, we support about 3 * 10^38 addresses in the address space.
> > That is a mathematically accurate statement.
> 
> No.  A mathematically correct statement would be that IPv6 can, in
> theory, address up to about 3*10^38 objects.  The number of objects
> that can actually be supported is, of course, far, far less.

The HD ratio equations predict that with 64 bit prefixes, we can number
N = 2^(hd*64) subnets. The current RIR policy assumes hd >= 80%, which
leads to N > 2.59 E+15 subnets. Make that 1E+15 for simplicity. 

In theory, 64 bits and DAD easily accommodate 2^32 hosts, but in
practice the number of hosts in a subnet is dictated by economics and
technology. The average subnet may well contain barely more than one
node, and is unlikely to have much more than 10 today, leading to 1E+15
to 1E+16 nodes. 

In the future, we can imagine personal networks containing hundreds of
devices, so 1E+17 nodes looks plausible.

I cannot really imagine a scenario in which we use 1E+38 addresses.

-- Christian Huitema