Hi Everyone,
Thank you for attending. I would like to respond to some of the comments
made in the chat. Unfortunately, looks like the messages are missing
from the log. I only have a general sense of what they were as relayed
to me by third persons. Please, if you could, would you re-post those
comments to the list.
Generally three types of comments were relayed to me.
1. About problem statement.
In general terms, I distinguish problem statement as what the proposed
solution provides, makes technically possible from what the solution's
intended use is. I am assuming here, the comment was about the former,
more limited problem statement relating purely to technical
capabilities. In that regard, IPREF is solving the problem of traversing
address spaces that are not reachable through normal means of a network
protocol. This is somewhat more general than IPv4/IPv6 interoperability,
perhaps, because it deals with address domains within a single protocol
as well as address domains belonging to different protocols, like IPv4/IPv6.
For me it is sufficiently precise. I would like to see the actual
comment posted. It was asking for clarifications which is hard for me to
address without seeing the comment. Please, re-post to the list, if
possible.
2. About too broad a usage, especially relating to matters considered
not interesting.
Yes, it looks like I got a little over excited. It should have been
greatly reduced to the most pressing issue at hand, which is to help
with IPv6 adoption and transition strategies. Hopefully, you can look
past that and not hold it against the technology itself.
3. About comparison with existing technologies.
I am assuming this refers to NAT64/SIIT. Compared to those, IPREF offers
several advantages: massive scaling, NAT traversal, DNS publishing both
ways, no external translators to setup and maintain. It also covers
cases that NAT64/SIIT does not support.
Consider a case of an enterprise trying to transition gradually.
NAT64/SIIT are frequently ineffective due to complexity transitioning
interrelated services gradually. Such transition almost always involves
third party networks such as integrators, vendors, suppliers. Setting
up and maintaining NAT64//SIIT translation devices is a burden. It
requires allocation of global IPv4 addresses which most enterprises are
in short supply of. Coordination between involved parties don't make
things any easier. IPREF is a better fit because it does not require any
devices of that kind. Most importantly, IPREF does not rely on any
global IPv4 addresses (or IPv6 addresses). In such environment, it is
common that IPv4 hosts must reach services on newly converted IPv6
networks. SIIT falls well short in this task. Very limited with no
ability to publish in DNS. For IPREF it works the same way as in any
other case. No difference, DNS publishing available. Even the best case
for NAT64, the one involving IPv6 host accessing IPv4 services, does not
work too well because NAT64 cannot traverse NAT which is the norm in
such environment. NAT64 would require to allocate global IPv4 addresses.
IPREF can easily reach across NAT without allocating global IP
addresses. Such services, 'behind NAT', can be advertised in DNS without
consuming global IPv4 addresses. Sometimes in the transition, there
comes a case of IPv4-to-IPv4 over IPv6 Internet. There is just no
solution for it but IPREF works in that case the same as in any other
case. Generally IPREF works with any combination of IPv4/IPv6 over
either IPv4 or IPv6 Internet and in all these cases services can be
published in DNS without using up any global IP addresses. As the
transition progresses, there is a further problem dealing with new
servers added, removed, changed. This is far easier handled through
IPREF references than with complex mappings to global IPv4 addresses,
which are not available to being with.
All in all IPREF is more scalable, more flexible, more capable. We need
it for more complex cases. Please support this project.
Waldemar
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
