Battling human nature (Re: Prefix Delegation and hosts)

[Mark Smith]

Why pick /80 instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a
few steps in the race to the bottom.

Presumably if your goal is to allow downstream devices to futher segment
you will assign the shortest prefixes you can get away with in your
model. if your goal is micro-segmentation of things like for example for
containers or VMs, you'll probably assign as long as you can get away
with e.g. /126 /127 /128 which can be littered all over the address
space if you're so inclined.

I think you missed his point.
The moment anyone admits that a network can have less than 64bits of addressing to play with, then the sky will fall in, there'll be plagues of locusts, the world will end, and everyone will start getting /128 single addresses delegated to them. Thus, there should not be any document anywhere even admitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bottom of the pond use it as an excuse to delegate smaller than multiple /64s to their customers.

I think your scepticism is overlooking human nature.

Human nature is to try to avoid change and to do what is familiar. It
is motivated by the fear of the unknown.

Human nature is to try to be lazy by default - to do the minimum
necessary to achieve the intended outcome.

The combination of these two natures means trying to do the most
familiar with the least effort.

Since giving a site a single public address and having the site use
NAPT are the IPv4 norm, there will be a strong human tendency to try
copy that norm in IPv6 if possible. It would be "the most familiar
with the least effort".

If a norm of per-site IPv6 /128s and NAPT became reality, it also
makes deploying IPv6 pointless. The fundamental goal of IPv6 is to
have enough public addresses so that each host that wants a globally
unique and public IPv6 address can have one, for something in the
order of at least the next 30 years.

Allowing IIDs that are smaller than 64 bits and more specifically
arbitrary in size formally permits the creation of IIDs that may be
too small for the number of IPv6 hosts that somebody wants to attach
to the link.

That formality would act as a strong signal that the IPv4 norm of a
per-site single public address and NAPT is perfectly acceptable in
IPv6 - despite it being a direct contradiction to IPv6's raison
d'être.


Regards,
Mark.

[Mark Andrews]

This post might be inappropriate. Click to display it.

[Tom Herbert]

Post by Mark Smith

Why pick /80 instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a
few steps in the race to the bottom.

Presumably if your goal is to allow downstream devices to futher segment
you will assign the shortest prefixes you can get away with in your
model. if your goal is micro-segmentation of things like for example for
containers or VMs, you'll probably assign as long as you can get away
with e.g. /126 /127 /128 which can be littered all over the address
space if you're so inclined.

I think you missed his point.
The moment anyone admits that a network can have less than 64bits of addressing to play with, then the sky will fall in, there'll be plagues of locusts, the world will end, and everyone will start getting /128 single addresses delegated to them. Thus, there should not be any document anywhere even admitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bottom of the pond use it as an excuse to delegate smaller than multiple /64s to their customers.

I think your scepticism is overlooking human nature.
Human nature is to try to avoid change and to do what is familiar. It
is motivated by the fear of the unknown.
Human nature is to try to be lazy by default - to do the minimum
necessary to achieve the intended outcome.
The combination of these two natures means trying to do the most
familiar with the least effort.
Since giving a site a single public address and having the site use
NAPT are the IPv4 norm, there will be a strong human tendency to try
copy that norm in IPv6 if possible. It would be "the most familiar
with the least effort".
If a norm of per-site IPv6 /128s and NAPT became reality, it also
makes deploying IPv6 pointless. The fundamental goal of IPv6 is to
have enough public addresses so that each host that wants a globally
unique and public IPv6 address can have one, for something in the
order of at least the next 30 years.
Allowing IIDs that are smaller than 64 bits and more specifically
arbitrary in size formally permits the creation of IIDs that may be
too small for the number of IPv6 hosts that somebody wants to attach
to the link.

Mark,

I don't understand the basis for unilateral statements like this that
/64 is the _only_ usable prefix length and anything else work. Sure
/128, /127, /126 are silly, but I could surely believe that most sites
could use a /96 which allows 4B hosts in the network without resorting
to NAT or running out of IP addresses.

Tom

Post by Mark Smith
That formality would act as a strong signal that the IPv4 norm of a
per-site single public address and NAPT is perfectly acceptable in
IPv6 - despite it being a direct contradiction to IPv6's raison
d'être.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Mark Smith]

Hi Tom,
<snip>

Post by Tom Herbert

Post by Mark Smith
Allowing IIDs that are smaller than 64 bits and more specifically
arbitrary in size formally permits the creation of IIDs that may be
too small for the number of IPv6 hosts that somebody wants to attach
to the link.

Mark,
I don't understand the basis for unilateral statements like this that
/64 is the _only_ usable prefix length and anything else work. Sure
/128, /127, /126 are silly, but I could surely believe that most sites
could use a /96 which allows 4B hosts in the network without resorting
to NAT or running out of IP addresses.

Is unique host addressing the only requirement?


"48-bit Absolute Internet and Ethernet Host Numbers", July 1981
http://www.textfiles.com/bitsavers/pdf/xerox/parc/techReports/OPD-T8101_48-Bit_Absolute_Internet_and_Ethernet_Host_Numbers.pdf


"Xerox internets and Ethernet local computer networks use 48-bit absolute host
numbers. This is a radical departure from practices currently in use
in internetwork systems
and local networks."

"Ethernet host numbers are 48 bits long
[Ethernet80]. 48 bits can uniquely identify 281,474,977 million
different hosts! Since the Ethernet
specification permits only 1024 hosts per Ethernet system, the
question that is often asked is: "why
use 48 bits when 10, or 11, or at most 16 will suffice?" This paper
answers this question, and
describes the benefits of using large absolute host numbers. "

(I think there is quite a bit of significance in the date of that
paper - 35+ years of Ethernet deployment has provided plenty of
opportunity for that addressing size decision to be proven incorrect.)


Surely the global network layer address space should always be much
larger than a link-layer address space, and the portion of global
address space available on a link should be at least as large as the
link-layer's address space?

A network layer address space available on a link that it is at least
as large as the link-layer address space would ensure that a links
traffic capacity is the primary and fundamental constraint on the
number of devices that can be attached, rather than the ability to
uniquely identify them at either the link or network layers.

Your suggested /96 or 32 bit IIDs are still smaller than what the
hosts have at the Ethernet link layer. We could settle on /80s and 48
bit IIDs, which is what was described in the first edition of the IPv6
addressing architecture RFC, RFC1884.

For various reasons 64 bit IIDs evolved on from that per RFC7421. 48
bits is probably enough for other beneficial IID properties such as
security, privacy and low likelihood of collision.

However, is the effort of shifting from 64 bit IIDs back to 48 bit
IIDs worth the benefit of getting back those 16 bits?

Regards,
Mark.

[Manfredi, Albert E]

-----Original Message-----

Post by Mark Smith
Surely the global network layer address space should always
be much larger than a link-layer address space,

Yes, that's intuitively obvious.

Post by Mark Smith
and the portion of global address space available on a link
should be at least as large as the link-layer's address space?

That's problematic. The "link layer address space," in this instance, is not really an address space at all. It is instead a unique product ID code (manufacturer plus serial number). There's no reason to assume that an attempt at creating globally unique product IDs has any relation to the address provided in a globally routed network. It was just a convenient way of defining an interface, that was supposedly guaranteed to be unique, at least on that subnet.

Making the IID smaller than a product ID code should not be a problem. Look at your automobile's VIN. It's humongous. Surely, we're not going to insist that the VIN become part of the car's Internet address? It's just not logical to assume that a globally unique product ID code must be part of a global address. Although if we wanted to create a flat global address scheme, stripping off the address prefix completely, it would be a decent idea.

I think the argument about SLAAC IID collisions within a subnet prefix is reasonable. Maybe the privacy concerns too, but certainly not on all networks. But we shouldn't take this 64-bit religion too far?

Bert

[Simon Hobson]

Post by Manfredi, Albert E
Look at your automobile's VIN. It's humongous. Surely, we're not going to insist that the VIN become part of the car's Internet address?

Going off topic, already been done (sort of) - and the obvious security implications found out after the fact !
https://www.theregister.co.uk/2016/07/08/bmw_vulns/

And slightly related, the danger of having primary keys publicly visible
https://www.theregister.co.uk/2017/05/31/bikers_hack_jeeps_in_auto_theft_spree/

[Alexandre Petrescu]

off-topic, about the the press and automobile technology.

Post by Simon Hobson

Post by Manfredi, Albert E
Look at your automobile's VIN. It's humongous. Surely, we're not
going to insist that the VIN become part of the car's Internet
address?

Going off topic, already been done (sort of) - and the obvious
security implications found out after the fact !
https://www.theregister.co.uk/2016/07/08/bmw_vulns/

One should be careful with what the press says. Because, when that URL

Post by Simon Hobson
The first (and more serious) vulnerability creates a means for a
hacker to access another driver’s Vehicle Identification Number (VIN)
before changing in-car settings such as lock/unlocking the vehicle,

It obviously ignores that the VIN is required to be displayed under the
windshield. It must be there and visible.

One difficulty may be in the distance (it's written in smaller
characters), but certainly in the reach of longer lenses.

Others pointed that VIN identification is readily available on the OBDII
port to CAN networks of some automobiles. If it's a risk, then maybe
CAN network managers should protect that CAN.

On another hand, if we need to consider the privacy of some identifier
of some car, that may be the MAC address of 802.11-OCB beacons (DSRC)
that may be periodically advertised by cars, and sniffed by anyone along
the road.

The MAC address could be considered as a 'signature' that is not
required to be public, and is hence private. Or maybe they will want it
to become public...

Alex

[Simon Hobson]

Post by Alexandre Petrescu
One should be careful with what the press says.

Indeed.

Post by Alexandre Petrescu
On another hand, if we need to consider the privacy of some identifier
of some car, that may be the MAC address of 802.11-OCB beacons (DSRC)
that may be periodically advertised by cars, and sniffed by anyone along
the road.
The MAC address could be considered as a 'signature' that is not
required to be public, and is hence private. Or maybe they will want it
to become public...

That is indeed going to be an interesting discussion. Sadly, in these days when so many people see no problem filling the data silos of the likes of FaceBook, I can see a lot of the public going "meh ?" and not seeing any problem with it.

[Mikael Abrahamsson]

Post by Tom Herbert
I don't understand the basis for unilateral statements like this that
/64 is the _only_ usable prefix length and anything else work. Sure
/128, /127, /126 are silly, but I could surely believe that most sites
could use a /96 which allows 4B hosts in the network without resorting
to NAT or running out of IP addresses.

Yes, and why would a home need more than a single network, thus a /64?
That's what a non-trivial amount of operators are doing right now. They PD
/64 and only that.

It's silly, it only allows single network in the home, but it's most
likely due to copying IPv4 thinking that this happened. If we didn't have
the /64 hard limit, they'd probably hand out a lot smaller network than a
/64.

So the thing is that if we allow smaller than /64, then if /96 is then
enough for a user, then perhaps /112 is enough, or a /120 is enough, or
why not a /124? Most people don't have more than 14 devices right?

Or perhaps why do you even need more than a single address, it's working
so great in IPv4, so there you go.

I know there is fundamental disagreement on this topic, and I don't think
we'll make people change their minds anytime soon about what they believe
will be the consequence of changing the /64 default.

[Brian E Carpenter]

On 21/07/2017 19:46, Mikael Abrahamsson wrote:
...

Post by Mikael Abrahamsson
I know there is fundamental disagreement on this topic, and I don't think
we'll make people change their minds anytime soon about what they believe
will be the consequence of changing the /64 default.

Who's proposing to change it? Currently it isn't a default, it's fixed.
The strongest proposal I've seen is to state that it's a default rather
than a fixed value.

Brian

[Lee Howard]

Top-posting because I'm posting from a phone in a hospital room.

1. We can't change the protocol while promoting it to Internet Standard.
2. I am interested in seeing what happens in the field and what people do with all the bits.

Lee

Sent from my iPhone

Post by Mark Smith

Why pick /80 instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a
few steps in the race to the bottom.

Presumably if your goal is to allow downstream devices to futher segment
you will assign the shortest prefixes you can get away with in your
model. if your goal is micro-segmentation of things like for example for
containers or VMs, you'll probably assign as long as you can get away
with e.g. /126 /127 /128 which can be littered all over the address
space if you're so inclined.

I think you missed his point.
The moment anyone admits that a network can have less than 64bits of addressing to play with, then the sky will fall in, there'll be plagues of locusts, the world will end, and everyone will start getting /128 single addresses delegated to them. Thus, there should not be any document anywhere even admitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bottom of the pond use it as an excuse to delegate smaller than multiple /64s to their customers.

I think your scepticism is overlooking human nature.
Human nature is to try to avoid change and to do what is familiar. It
is motivated by the fear of the unknown.
Human nature is to try to be lazy by default - to do the minimum
necessary to achieve the intended outcome.
The combination of these two natures means trying to do the most
familiar with the least effort.
Since giving a site a single public address and having the site use
NAPT are the IPv4 norm, there will be a strong human tendency to try
copy that norm in IPv6 if possible. It would be "the most familiar
with the least effort".
If a norm of per-site IPv6 /128s and NAPT became reality, it also
makes deploying IPv6 pointless. The fundamental goal of IPv6 is to
have enough public addresses so that each host that wants a globally
unique and public IPv6 address can have one, for something in the
order of at least the next 30 years.
Allowing IIDs that are smaller than 64 bits and more specifically
arbitrary in size formally permits the creation of IIDs that may be
too small for the number of IPv6 hosts that somebody wants to attach
to the link.
That formality would act as a strong signal that the IPv4 norm of a
per-site single public address and NAPT is perfectly acceptable in
IPv6 - despite it being a direct contradiction to IPv6's raison
d'être.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------