When NCP was changed to TCP in a hot cut, no one even considered that
maybe that would have been a good time to increase the number of bits in
IPv4 addresses. Because that was a hot cut, that would have been the
perfect time to do this, but of course this would have increased the work
load to do so, since every piece of network software assumed 32 bits at
this time and would have had to be updated and recompiled. At this time,
the number of nodes was under 1k and a billion addresses seemed like it
would never run out. If we slid that to say 64 bits at that time, I doubt
that IPv6 (IPng) project would have ever been started. But it did not,
and we still are stuck with a 32 bit IPv4 address.
During the entire time since TCP over IPv4 started, the "default"
expectation was that each workstation or server would be given its own
public address. The same thing is also considered the default in IPv6, and
the idea of NAT on IPv6 was not seriously considered is the fact that
every network already has more public addresses than all of IPv4, thus
there is no real need for NAT for address sharing.
It was during the 1990's that NAT first started. I used it in Linux with
SLIP and later PPP. Each of these gave you a single dial up public
address, which I could then share with other workstations over ethernet.
During the dialup age, I used to provide Dial on Demand boxes that would
bring up a dialup connection during the time when full time connections to
the internet were rare and hard to get. When ADSL became available, that
modem set on its own ethernet card with its single public address, and was
shared by all the workstations on the LAN which was another ethernet card
operating on RFC1918 addresses.
During this time, we did NAT not for lack of addresses, but for a easy way
to connect additional workstations to the public address that I had. It
was also common during this time to use routers connected to the modem to
share the single IPv4 address, just like today. This was initially done as
a cost saving measure to avoid paying extra to route a network of public
addresses when a public address was not needed on each of the attached
workstations.
Eventually, the idea of obtaining a public address for every workstation
became uncommon as ISP's started charging for more than one address. This
became especially true when the IPng started with the 6bone, and we could
see that the IPv4 free pool would run out, which happened in 2011.
The true answer to this is to to get the IETF or others to figure out how
to get routing to work correctly on a network that has more than one
router and more than one available PA network address block. This
configuration could not only be used for multihoming, but could be also
used as a means to increase available bandwidth on a given network by
obtaining additional bandwidth from another provider. The v6 stack in
common OS's need to learn how to adjust routing when perferred lifetime=0
broadcasts are received when a link is down, and also to properly divide
bandwidth use between the available networks that are up. The only part
that seems to currently universally work is the assignment of an address
on each network when there are more than one available. After that, many
OS's including windows choke, especially if the specific network the
workstation has chosen as its default route happens to fail.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 13 Sep 2021, Joe Maimon wrote:
JORDI PALET MARTINEZ via ARIN-PPML wrote:
Definitively any organization or even an individual user that want to have
its own IPv6 PI must be able to get it.
Anything that can promote ULA+NTPv6 (which by the way it is an experimental
protocol, not to be used in production), is evil and for that, we better
don?t waste our time to move to IPv6 and instead promote infinite levels of
IPv4 NAT.
The unceasing controversy over NAT has done nothing but delay IPv6 adoption.
Standardize it and let people use it or not, as they may choose. Stop
channeling BOFH.
Joe
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
