Philip,
On 20/1/21 17:06, Phillip Hallam-Baker wrote:
[...]
The background to this proposal is as follows:
0) Nowhere does the 'end to end' principle demand that the source and
destination addresses on an IP packet remain constant.
The end-to-end principle are guideliness, rather than specific mandates.
IPv6 is (was?) supposed o be end-to-end, and address translation (which
you seem to be implying) goes against simplicity and robustness.
1) NAT is here to stay. IPv6 does not eliminate the need for NAT except
for enterprises which 'own' their IPv6 address blocks.
I won't challenge this.
I have IPv6 service from Verizon but I obviously can't use it on my
internal network because my IPv6 address changes every few months. This
is certain to be the case for virtually every residential Internet drop
and the vast majority of business customers.
Depends on what you're implying. You could certainly use them, and the
network would eventually gracefully renumber.. -- whether this would be
practical, is a different question.
2) NAT multiplexing will become an increasing problem
Current NAT conflates two functions. The function of translating IP
addresses at the network boundary will continue to be motivated by
operational and security concerns that are not going to go away.
The function of multiplexing multiple hosts onto a single IPv4 Internet
address is never going to go away but only for the limited number of
Internet hosts that require that access.
These two are essentially variants of the same thing.
I have a very large number of
IP connected devices in the house but I really don't want the coffee pot
talking to the open Internet.
You do not need a NAT for that: you can deploy a firewall.
As people end up with thousands of devices inside their home, port
exhaustion at the NAT box and the ridiculous complexity of it all is
going to become a major headache. Sharing one IP address between 100
hosts works, its not ideal but it works right up to the point where you
decide that you need fault tolerance and you are going to need two NAT
boxes and the mapping data has to be synchronized.
You don't need this for IPv6. i.e., even if you translated (NPT) , you
don't need to multiplex all hosts into the same address -- this is/was
done in IPv4 because IPv4 addresses are scarce. BUt that's not the case
with IPv6.
Solution
The solution is to provide a non-routable space where address block
collisions are unlikely.
Welcome to ULAs: RFC4193
The only ways to avoid collisions are either to (1) randomly assign
spaces in a sufficiently large space or (2) have a registrar whose
function is to guarantee uniqueness.
FWIW, ULAs do (1).
[...]
This is probably sufficient. But a registry model would make for more
efficient allocation of the space and allow the allocation to be bound
to a public key whose private part is held by the registrant.
That comes at the price of running the registry. And I'm curios: if
you're going to pay, why not get a routable prefix, and simply not
announce it via BGP?
[...]
So this allows traffic patterns where as far as Alice's mobile and Bob's
desktop are concerned, a communication is established on the 2002://16
net and is constant the entire time. But behind the scenes, those
addresses are being mapped to/from Internet routable addresses at the
network boundary and those mappings are changed dynamically as Alice
moves about from her home IP network, to her wireless provider, to her
company provider. If she is at home and a tree takes out her Fios (like
happened to me), her mobile provider simply kicks in without a pause.
You don't need a registry for this. You can achive the same thing with
ULS + NPT.
Or even worse, we should fix IPv6's support for multi-prefix/multi-link
networks, which is known to be broken.
[Yes, I know there are similar ideas. But having an assigned private
address space that is globally unique but not used for Internet routing
helps simplify those as well]
Regarding globally-uniqueness, you may want to check the ULA spec
(RFC4193) and this:
https://tools.ietf.org/html/draft-gont-6man-ipv6-ula-scop
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
