Hi Jen,
Thanks for paying attention. I appreciate that. First thing that comes
to mind is that I don't know if the assumptions implied by your post
hold true. It kind of reminds me of the early criticism of NAT. As we
know, NAT was developed at about the same time as IPv6, some 25 year ago
and is doing very well in spite of heavy push against it initially.
IPREF, like NAT, is an address rewriting technology so I guess I should
expect similar trajectory. But by the same token, since some of the
assumptions from that era proved false, I could reasonably expect some
assumptions now may prove false too. Address rewriting, for example.
Wasn't it supposed to disappear? It did not. I think address rewriting
is here to stay. Why do people, some of them, insist on NAT6? We can't
just ignore them. They're not stupid, they are telling us something, we
must understand them. Allow for a moment, that NAT6 lives, then your
item (1) is a false assumption. Sorry, I am just making a point. Is
IPv4 going to disappear? If it does, it does not seem like it will
happen anytime soon. IPv4 is still a reality, it is in play. Now, I am
not advancing IPv4, far from it. I am advancing innovation in
networking. IPREF works not only with IPv4 and IPv6. It works with just
about any network protocol. IPREF will allow development of new
protocols without a fear that they will be instantly incompatible and
thus not worthy even considerations. IPv6 was designed for the Internet.
Maybe it should stick to its original mission. Maybe it should not try
to pretend that it can solve every problem at every network. Some local,
private networks, would benefit from the ability to customize for their
purpose. Be it financial with extra security and audit, military with
different type of security, be it space with fluid time domain, be it
IoT with low power low bandwidth. I want to give them a chance.
Incidentally, it's rather obvious to me that IPREF will speed up
adoption of IPv6 Internet. I think that alone is worth the effort.
Why? Because if you allow IPREF, and especially if IPREF addressing
for public services gains some popularity, then there is no reason to
keep providing IPv4 addresses (and thus the IPv4 Internet). Folks can
even keep their local IPv4 networks until they decide what to do with
them. Those admins of larger private networks resist because they don't
want to mess with them but they would swallow a gateway that can get
them off the hook. With IPREF, it will be possible to take down IPv4
Internet waaay before scorched earth push forces everyone to switch. I
say don't bully them, entice them softly instead. Oh, and that dual
stack on every device, including my refrigerator? It can be put to rest
even sooner. This is an incredible tax on the entire industry. Folks
should just run whatever protocol they choose for the network. Dual
stacks are for the gateways.
So while it is true I started with addressing some of the super annoying
problems with peer networking, that last bullet item on slide 3 is the
long term super benefit. [...but notice, ‘public’ addresses are merely
exposing hosts located on private networks]. It requires some
imagination to see it. It took me time to realize it, so I expect this
will need more processing.
Now (2) and (3) are known, sure, but aren't very popular, mostly because
they're incomplete, require complicated setup, negotiations, or both.
Few would consider configuring STUN servers. Think of corporations
trying to reach their disjoint private networks, not happening. NAT64
you say? Non-starter. How about those gamers on the Internet? Do you see
them doing any of this? With IPREF they would just buy a small router
that would make a magic happen for them. It matters.
In short, (2) and (3) nominally exist but the problem still does, too.
So maybe assumptions about their effectiveness should be adjusted.
So yes, end2end, no negotiations, deal with address overlaps, deal with
NAT, traverse protocol domains, DNS publishable, 100% local network
admin, no external servers/brokers, no global registries.
As for the effort, essentially we need to find the place for the
reference. In reality, this probably means defining an extension header
plus a tunnel because headers are notoriously dropped and because for
IPv4 we probably don't want to define any more options (which would be
dropped anyway). There is also some DNS related work, maybe defining an
RR. The format of the reference itself, even if the contents are
considered opaque, probably needs some discussion.
On 3/28/23 02:00, Jen Linkova wrote:
Waldemar,
Would you be able to elaborate on the problem statement and the
benefits of the proposed solution?
After reading the draft and listening to the presentation I'm not sure
I fully understand the problem. It looks like your goal is to achieve
a kind of end2end.
However:
1) We do not need anything for IPv6-to-IPv6 end2end.
2) For IPv6-to-IPv4 we have NAT64, and for IPv4-to-IPv6 we have SIIT.
3) For IPv4-to-IPv4 we have some forms of NAT-T and STUN.
If your goal is to replace #2 and #3 with a one protocol to rule them
all, I'm not sure we shall put too much effort (time and money) into
developing new solutions for the legacy protocol version. Especially
as we expect IPv4 to decline over time.
Am I missing some key benefits of the proposed solution which would
make IPREF attractive enough to deploy instead of existing solutions?
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
