Subject: Re: Why /64

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Nov 2013 20:20:30 +1100

In message <[email-masked]>, Ray Hunter writes:
> 
> 
> Mark Andrews wrote:
> > In message <[email-masked]
> ing.com>, "Manfredi, Albert E" writes:
> >>> -----Original Message-----
> >>> From: Brian E Carpenter [mailto:[email-masked]]
> >>> Because there are trillions of /48s.
> >> And we think that is way more than adequate, today. Until the paradigm cha
> nges, and every vehicle, every street, e
> >> very building, every person, will need its own internal subnet structure. 
> For things like vehicle-to-infrastructur
> >> e comms, vehicle-to-vehicle comms, internal vehicle controls and diagnosti
> cs (separated into multiple subsystems o
> >> f course), wearable medical sensors, and who knows what else. And space.
> >>
> >> I'm just saying, classful IPv4 also seemed like plenty at first. It was a 
> mere decade before we knew differently.
> >
> > No classful IPv4 was *known* to not scale from the very beginning.
> >
> > There are 72057594037927936 /56's which are what most ISP are
> > planning to hand out to residential customers.
> >
> > If you really want to be miserly you can request /64's on a needs
> > basis with PD which is what internal home routers will need to do
> > so the code to support this will exist if we ever need to got to
> > that level when talking to ISP's.
> 
> Which would be fine if:
> 
> 1) All allocations continue to be made by ISPs on a network provider =>
> consumer model

Consumers dominate delegations.
 
> 2) We had a routing mechanism that could handle such a flat addressing
> structure

ISP's would still be aggregating the routes. 

> 3) We had a delegation mechanism for naming and addressing that could
> easily cope with delegation on bit boundaries.
> but we don't.

But we do. It really isn't that hard to a delegate 8 zones (worst case)
over 1.
 
> 1. More and more we see demand from manufacturers e.g. car engine
> management, and even subcomponent management.
> 
> 2. We have a very limited number of bits of hierachy for route
> aggregation, and thus effectively a limit to the hierarchical depth of
> network topology/ organisations.
> 
> 3. Once you factor in recommendations to delegate on nibble boundaries
> (e.g. for DNS) you have somewhere around /32 to /64 = ±9 nibble
> boundaries => 9 levels of depth of hierarchy + a flat LAN.

If you are allocating /64's you *are* allocating on a bit boundary.
 
> IMHO I think what we effectively have is an administrative
> (non-technical) limit to scaling today, largely limited by an ability to
> register, delegate, and aggregate; rather than the huge number of
> possible addresses or prefixes. 'twas ever thus. In IPv4 it was
> effectively +/- 3 levels (octet boundaries + a flat LAN).
> 
> regards.
> 
> >> Bert
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [email-masked]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> 
> -- 
> Regards,
> RayH
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Fri, 01 Nov 2013 11:56:59 +0100

> Mark Andrews <mailto:[email-masked]>
> 1 November 2013 10:20

In terms of numbers. Currently. The scaling limit is hierarchical
complexity. Not the total absolute numbers of elements.
That's exactly the same mistake made in IPv4 to start with when
designing class-based routing.
> ISP's would still be aggregating the routes. 
Only if the connection runs over an ISP link, and only at Internet
global level.
The Internet is more than ISPs.
> But we do. It really isn't that hard to a delegate 8 zones (worst case)
You are thinking technically. Try getting outsourcing partners to share
management responsibility for a zone or address space.

> If you are allocating /64's you *are* allocating on a bit boundary.
Take off your techie hat and put on an administration hat and start
thinking organisational complexity (who manages space, who configures
DNS, who configures aggregation, who configures DSCP pattern matches,
who configures firewall rules?)

Have you ever produced an IPv6 numbering plan for an enterprise?
Rather than an ISP with a flat org structure?

If people start building in organisational elements or other semantics
into the numbering plan (to allow delegation of space/control to people
or organisations or automated processes, or to simplify ACL pattern
matches, or management, or whatever) you get close to running out of
hierarchy quite quickly.

Here's an 8 level hierarchy already

<top level org allocation><regional BGP breakout><sub region for more
granular breakout in the future><country><site><outsourcing
org><department><lan type>

You can argue whether this is a sensible allocation structure. But
that's equivalent to 7 nibbles after the top level allocation, with one
nibble per element. If you have large numbers of elements at any level
of the hierarchy, you need more than one nibble. So that's already bits
from /32 to /64 completely filled on day one. CIDR beyond /64 would
allow some more room for manoeuvre/ creativity to tie yourself in knots.
Delete as appropriate.

But in any case, the scaling limit on hierarchy is many orders of
magnitude lower than your suggestion/assumption of 72057594037927936
flat /56 allocations.

-- 
Regards,
RayH

---

From: Brian Haberman <[email-masked]>
Date: Fri, 01 Nov 2013 08:35:02 -0400

Hi Bert,

On 10/31/13 8:59 PM, Manfredi, Albert E wrote:
>> -----Original Message----- From: Mark Andrews
>> [mailto:[email-masked]]
> 
> 
>> Because at 20 billion people you have 3 million networks per person
>> with /56's.
>> 
>> (2^56)/(2*10^10) = 3602879
> 
> But this continues to miss the point. It used to be mainframes at
> organizations. Then it became PCs in homes and offices. Then it
> became PCs and cell phones and tablets and printers and scanners and
> ...
> 
> Now think of beacons at road edges, potholes, road signals, street
> lights, crosswalks, yield signs, lane merge, nature trail, bike path,
> shipping lane, buoys, and so on, in addition to what you might have
> now associated with people, homes, offices. It's not just associated
> with people anymore.
> 
> All of these need organizational networks. Not all of these networks
> need anywhere close to 2^64 hosts apiece. Why would you need 2^64
> IIDs for a subnet of neighborhood streetlights, for instance?

I had an interesting conversation with a group of folks interested in
building networks just like you describe (i.e., road signs, buoys, lane
markers, etc.).  They did not seem to think the /64 boundary was a
problem mainly because they did not see these networks using globally
addressable addresses.

Just a data point.

Regards,
Brian

---

From: Ralph Droms <[email-masked]>
Date: Fri, 1 Nov 2013 10:16:58 -0400

> problem mainly because they did not see these networks using globally

I don't think the /64 boundary is important even if those devices are using global addresses.  Presumably there is some route aggregation somewhere that puts these networks behind a /mumble that's compatible with Internet core routing, and the other endpoints exchanging traffic with these nodes using /(greater-than-64) just see the 128-bit endpoint address and are agnostic about the length of the prefix.

One could imagine using a technique like this to mitigate some multi-link subnet problems by allowing prefixes /(greater-than-64) within the subnet while advertising a single /64 from a border router.

- Ralph

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 1 Nov 2013 20:25:22 +0000

> I don't think the /64 boundary is important even if those devices are using
> global addresses.  Presumably there is some route aggregation somewhere that
> puts these networks behind a /mumble that's compatible with Internet core
> routing, and the other endpoints exchanging traffic with these nodes using
> /(greater-than-64) just see the 128-bit endpoint address and are agnostic
> about the length of the prefix.
> 
> One could imagine using a technique like this to mitigate some multi-link
> subnet problems by allowing prefixes /(greater-than-64) within the subnet
> while advertising a single /64 from a border router.

Exactly my thought. For example, I would consider assigning a /64 to each automobile. Then inside the auto, a 16-bit prefix, to create a lot of /80 subnets, for each internal system. Something along those lines.

Route aggregation would be at the /64 address.

Brian believes that this approach would be IPv4.1, because his emphasis is more on IID length to facilitate SLAAC. Instead, I think it's IPv6, because it goes way beyond 32 bits (and NAT!!) of IPv4, to get decent distribution of networks.

Plus, there's nothing set in stone that says SLAAC can't be done with fewer than 64 bits of IID. The chances for collisions goes up, however the number of hosts assumed per subnet would typically be fewer, mitigating that problem. (Host discovers subnet mask from RA, and configures its SLAAC address accordingly.) And then you use DAD. Besides which, my in-home router/modem seems to have no problem doing its own DHCP anyway, so this isn't exactly a show stopper.

As to the various beacons and digital signs and so on, global addressing makes sense for these, if one plans on using them for any and all vehicles. Same deal with wearable medical sensors on people. Of course, other addressing schemes could also be used, such as NSAPAs. ;)

Bert

---

From: Brian Haberman <[email-masked]>
Date: Fri, 01 Nov 2013 16:30:50 -0400

Hi Bert,

On 11/1/13 4:25 PM, Manfredi, Albert E wrote:
>> I don't think the /64 boundary is important even if those devices
>> are using global addresses.  Presumably there is some route
>> aggregation somewhere that puts these networks behind a /mumble
>> that's compatible with Internet core routing, and the other
>> endpoints exchanging traffic with these nodes using 
>> /(greater-than-64) just see the 128-bit endpoint address and are
>> agnostic about the length of the prefix.
>> 
>> One could imagine using a technique like this to mitigate some
>> multi-link subnet problems by allowing prefixes /(greater-than-64)
>> within the subnet while advertising a single /64 from a border
>> router.
> 
> Exactly my thought. For example, I would consider assigning a /64 to
> each automobile. Then inside the auto, a 16-bit prefix, to create a
> lot of /80 subnets, for each internal system. Something along those
> lines.

For things like automobiles I am not sure why you need more than one
subnet, but OK.

> Brian believes that this approach would be IPv4.1, because his
> emphasis is more on IID length to facilitate SLAAC. Instead, I think
> it's IPv6, because it goes way beyond 32 bits (and NAT!!) of IPv4, to
> get decent distribution of networks.

I am pretty sure I did not make any such statement, but maybe you are
referring to Brian C.

> 
> Plus, there's nothing set in stone that says SLAAC can't be done with
> fewer than 64 bits of IID. The chances for collisions goes up,
> however the number of hosts assumed per subnet would typically be
> fewer, mitigating that problem. (Host discovers subnet mask from RA,
> and configures its SLAAC address accordingly.) And then you use DAD.
> Besides which, my in-home router/modem seems to have no problem doing
> its own DHCP anyway, so this isn't exactly a show stopper.
> 
> As to the various beacons and digital signs and so on, global
> addressing makes sense for these, if one plans on using them for any
> and all vehicles. Same deal with wearable medical sensors on people.
> Of course, other addressing schemes could also be used, such as
> NSAPAs. ;)
> 

The *only* purpose of my original e-mail was to provide a data point on
how some people looking at new types of networks are thinking about
addressing.

Regards,
Brian H.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 1 Nov 2013 20:54:53 +0000

> From: Brian Haberman [mailto:[email-masked]]

> For things like automobiles I am not sure why you need more than one

Because for many reasons, you will want to split out the different systems into their own subnets. For instance, engine controls would want to be separated and firewall protected from, say, the onboard entertainment net, from the windows and seat adjustment net, from the internal and exterior lighting nets, from the ABS and stability control, and so on. Primarily this has to be done for safety, but it also allows the different system vendors to design a system which can then be dropped into any vehicle, without affecting the other subsystems.

The global addressing is useful for software updates and for vehicle-to-infrastructure comms (those comms which wouldn't strictly be done at layer 2 only for the shortest range needs). Systems like OnStar do some of this already, on a smaller scale of course, using telephone numbers as the globally unique address. You get a fairly comprehensive report card on your car periodically, from OnStar. This could be taken a whole lot further. And for some fixes, e.g. for recalls that have to do with reflashing ROM, it's conceivable that updates could be done remotely (when the car is stopped, of course, which would be easy enough to determine remotely).

Bert

---

From: Brian Haberman <[email-masked]>
Date: Fri, 01 Nov 2013 17:08:53 -0400

On 11/1/13 4:54 PM, Manfredi, Albert E wrote:
>> -----Original Message----- From: Brian Haberman
>> [mailto:[email-masked]]
> 
>> For things like automobiles I am not sure why you need more than
>> one subnet, but OK.
> 
> Because for many reasons, you will want to split out the different
> systems into their own subnets. For instance, engine controls would
> want to be separated and firewall protected from, say, the onboard
> entertainment net, from the windows and seat adjustment net, from the
> internal and exterior lighting nets, from the ABS and stability
> control, and so on. Primarily this has to be done for safety, but it
> also allows the different system vendors to design a system which can
> then be dropped into any vehicle, without affecting the other
> subsystems.

I think that it is critical that control functions related to the
operation of the vehicle be physically separated from networks being
used by on-board users.  That separation is probably why we view the
addressing scheme differently.

Regards,
Brian H.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 02 Nov 2013 11:46:29 +1300

>> emphasis is more on IID length to facilitate SLAAC. 

That was Brian C., and what I said (or meant to say) is that if there
hadn't been arguments at the time (1994) for having a free hand with
the host identifier, quite distinct from the CIDR issues that were
driving all IPv4 thinking at the time, we would simply have gone for
fully CIDRised 64 bit addresses. In that case we'd likely have ended
up with de facto subnet size limits in the 256-1024 range, I'm guessing,
and no chance of doing anything like privacy addresses.

I would also dispute that strict hierarchical address allocation
with perfect aggregation is necessary in corporate networks. Aggregation
at site level should be sufficient. A company with a /32 could have
16 bits for routing between sites and 16 bits for routing within sites,
and lots of flexibility too.

  Brian C

Instead, I think
> ------------------------------------------------------------------------
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 2 Nov 2013 12:21:10 +0900

On Sat, Nov 2, 2013 at 5:54 AM, Manfredi, Albert E <
[email-masked]> wrote:

> Because for many reasons, you will want to split out the different systems
> into their own subnets. For instance, engine controls would want to be
> separated and firewall protected from, say, the onboard entertainment net,
> from the windows and seat adjustment net, from the internal and exterior
> lighting nets, from the ABS and stability control, and so on.
>

Do we not have enough space to assign cars /60s? We already assign /60s to
residential subscribers.

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 2 Nov 2013 10:28:44 +0100

On Fri, Nov 1, 2013 at 2:48 AM, Brian E Carpenter
<[email-masked]> wrote:
<snip>

> If we'd just wanted to do IPv4.1, we'd have picked 64 bits
> instead of 128. As it is, we have 64 bits for CIDR and 64 bits
> for new ideas.

This is probably the best reason I've heard ever on why keep /64.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Peter Dordal <[email-masked]>
Date: Sat, 02 Nov 2013 10:58:47 -0500

I draw attention to the following from RFC4291, emphasis added:

    For all unicast addresses, **except those that start with the binary
    value 000**, Interface IDs are required to be 64 bits long

This goes back to RFC 2373, though not to RFC 1884.

As far as I can make out, the 64-bit IID length comes from SLAAC;
DHCP6 is perfectly fine with obtaining a /96 (or even /120) prefix
and handing out host addresses within that space.

If the concern is that /64 leaves us with not enough address bits,
one approach would be to revisit the need for SLAAC. That would be
controversial, though perhaps not as controversial as a few years ago.

But another approach is to observe that some different IID strategy
can be used within the 0::/3 block mentioned above by RFC 4291.
For example, the 1000::/8 block could be required to use 32-bit IIDs.
This would leave 2^88 address prefixes, 16 million times the
2^64 prefixes available with /64. And perhaps the 1100::/8 block
could use 12-bit IIDs, and so on.

Holding back even a modest fraction of the address space from
the /64 rule, in other words, is quite effective insurance against
unanticipated future needs for light bulbs and sensor motes.

Finally, I do remain concerned that if the prefix length is
entirely at the discretion of the ISP, then some of us will
end up with /128.

Peter Dordal
Loyola University Chicago

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Nov 2013 09:11:38 +1300

> controversial, though perhaps not as controversial as a few years ago.

There's another thread that shows that it's still highly controversial,
over on v6ops.

> can be used within the 0::/3 block mentioned above by RFC 4291.

Actually we have even more flexibility than that, since the only
prefix that is available for GUA is 2000::/3. That's where our stock
of 35 trillion /48s resides. (2**45 = 35,184,372,088,832)

In other words, even if we leave 0::/3 and 2000::/3 exactly as they
are, we still have three-quarters of the address space completely
untouched - and that was intentional, in case we mess up.

Since I expect 35 trillion /48s to last for several centuries, assuming
we continue to apply CIDR wisely throughout 2000::/64, I truly don't
lose sleep over any of this.

...
> entirely at the discretion of the ISP, then some of us will

Absolutely. I would lose sleep over that.

   Brian Carpenter

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 2 Nov 2013 17:15:56 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: "Manfredi, Albert E" <[email-masked]>
> Cc: IETF IPv6 Mailing List <[email-masked]>
> Sent: Friday, 1 November 2013 8:50 AM
> Subject: Re: Why /64
> 
> On 01/11/2013 10:24, Manfredi, Albert E wrote:
>>>  From: Erik Kline [mailto:[email-masked]]
>>>  Sent: Thursday, October 31, 2013 5:20 PM
>>>  To: Manfredi, Albert E
>>>  Cc: IETF IPv6 Mailing List
>>>  Subject: Re: Why /64
>>> 
>>>>  If a residence, or an automobile, is assigned a /64, presumably any 
> routing
>>>  from the WAN will be aggregated to that home or vehicle already. Then 
> inside,
>>>  your gateway takes care of the rest, no?
>>> 
>>>  No gateway currently does this, i.e. it will not "just work" 
> today.
>>> 
>>>  Furthermore, I would argue that no home gateway currently expects that
>>>  it should do this, since it hasn't been documented as a 
> requirement.
>>> 
>>>  That's the kind of stuff to which I was referring.
>> 
>>  Understood. And I find this troubling and unnecessary. That's my point. 
> We have this huge 128-bit address space, and we are putting ourselves in a 
> position where we actually only have maybe 48 or at most 56 bits of 
> "distribution potential," meaning "to different sites." 
> Where IPv4 with CIDR has essentially 32. How come this isn't troubling?
> 

And (using the ARIN XX-Small costs from before), a /48 only costs $1.95 per annum. That's cheaper than most, if not all items in the office stationary cupboard. If you can't get your customers to cover that cost, then I think your business has far bigger problems to worry about (or is worrying about the wrong things).

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 2 Nov 2013 17:38:22 -0700 (PDT)

----- Original Message -----
> From: "Manfredi, Albert E" <[email-masked]>
> To: Brian E Carpenter <[email-masked]>
> Sent: Friday, 1 November 2013 9:06 AM
> Subject: RE: Why /64
> 
> And we think that is way more than adequate, today. Until the paradigm changes, 
> and every vehicle, every street, every building, every person, will need its own 
> internal subnet structure. For things like vehicle-to-infrastructure comms, 
> vehicle-to-vehicle comms, internal vehicle controls and diagnostics (separated 
> into multiple subsystems of course), wearable medical sensors, and who knows 
> what else. And space.
> 

I think the thing forgotten about IPv4 was it was never meant to scale to be a world wide network interconnecting everything - it was sized to suit an experimental network. Here's the thinking behind the original 32 bit address size choice:

http://mailman.nanog.org/pipermail/nanog/2010-April/020488.html

IPv6 could be seen to be the first networking protocol designed to solve a world-wide internetwork problem connecting all devices for which it might be useful. That includes devices where it would be useful for no other reason than the manufacturer wants to update the device's firmware, including toasters:

http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8813.mm.www/0237.html

Regards,

Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 2 Nov 2013 18:05:43 -0700 (PDT)

----- Original Message -----
> To: Brian Haberman <[email-masked]>
> Cc: "[email-masked] List IPv6" <[email-masked]>; Ralph Droms <[email-masked]>
> Sent: Saturday, 2 November 2013 9:46 AM
> Subject: Re: Why /64
> 

As a data point to support this, I worked on an state government network in the late 1990s that had 500 routers, 700 routes and no aggregation at all. That's not to say that is a great idea, but routers with Motorola 68K class CPUs and 2MB of RAM had no trouble with flat routing on that scale, so flat routing on a much larger scale than that today is likely to be no problem.

Regards,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 29 Nov 2013 14:59:03 +0100

sidenote about this intriguing bit...

Le 25/10/2013 07:16, Fred Baker (fred) a écrit :
[...]
> and note that the IEEE is now (I'm told) discussing 128 bit MAC
> Addresses.

Found in draft-ieee-rac-oui-restructuring-00 section 4.4.2 'EUI-128 
addresses'.

Alex

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 Nov 2013 15:49:57 +0000

I attended .1 meetings in Dallas the week after Vancouver and the fashion was more around:

- cannot bridge 64  bits address (but the reason is more for incompatible MAC expectation in 15.4 like latency than for address translation reasons)
- should go back to EUI 48 for everything (and the reason was that changing all the mibs that have 48 bits in them is a nightmare)

Cheers,

Pascal

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: vendredi 29 novembre 2013 14:59
> To: Fred Baker (fred); Fernando Gont
> Cc: [email-masked]; <draft-gont-6man-deprecate-eui64-based-
> [email-masked]>
> Subject: Re: Deprecating EUI-64 Based IPv6 Addresses
> 
> Found in draft-ieee-rac-oui-restructuring-00 section 4.4.2 'EUI-128 addresses'.
> 
> Alex
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 30 Nov 2013 23:58:59 +0000

> - should go back to EUI 48 for everything (and the reason was that changing all the mibs that have 48 bits in them is a nightmare)

From my perspective, I really don't care how many bits any given technology uses. If they need a 92.5 bit address, they should use a 92.5 bit address. On the other hand, if they don't need a given address size, they should not concoct a reason to use it. The IETF should similarly use address sizes and structures that work will across a variety of lower layer technologies, and perform the unnatural act of tying itself to one of them, or appearing to. The value of a virtual address is that it maps to anything...

>> Found in draft-ieee-rac-oui-restructuring-00 section 4.4.2 'EUI-128 addresses'.

-----------------------------------
"We are learning to do a great many clever things...The next great task
will be to learn not to do them."

- G. K. Chesterton (1874-1936)

---

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Nov 2013 19:55:47 -0500

On Nov 30, 2013, at 6:58 PM, "Fred Baker (fred)" <[email-masked]> wrote:

> From my perspective, I really don't care how many bits any given technology uses. If they need a 92.5 bit address, they should use a 92.5 bit address. On the other hand, if they don't need a given address size, they should not concoct a reason to use it. The IETF should similarly use address sizes and structures that work will across a variety of lower layer technologies, and perform the unnatural act of tying itself to one of them, or appearing to. The value of a virtual address is that it maps to anything…

+ many lots…
W

-- 
Never criticize a man till you've walked a mile in his shoes.  Then if he didn't like what you've said, he's a mile away and barefoot.