Hi Eric and Eric
Hopefully you recall a few weeks back you asked Nalini and me to
meet with Waldemar, to find out more about IPREF. And to analyze it’s
viability from an enterprise network perspective.
We have had the opportunity to meet several times with Waldemar and
we would like to thank him for all of his help and all of the
information & answers he provided.
The following is a brief synopsis of our discussions and high level
conclusions.
We all feel we have taken this as far as practical, without further
feedback and/or guidance regarding if/when/how, to move forward on this
topic, from the two of you.
Please review the 4 sections below:
HIGH LEVEL AND BACKGROUND/REFERENCE INFORMATION ON IPREF
GENERAL POST ANALYSIS COMMENTS
ADDITIONAL INFORMATION AND COMMENTS REGARDING IPREF
SPECIFIC QUESTIONS AND ANSWERS.
Much more analysis and detail is required, but hopefully this is a
good start. and assists you in deciding what the next steps the next
steps We hope you find this informative, relevant to what you had asked
for and helpful for you as you determine what the next steps should be.
Please let us know, if you have any related questions.
Thanks
Mike
******************
HIGH LEVEL AND BACKGROUND/REFERENCE INFORMATION ON IPREF
https://github.com/ipref/ietf/blob/main/ipref-overview.md
https://github.com/ipref/ietf/blob/main/transition-to-ipv6-with-ipref.md
this is the current IETF Draft for IPREF.
draft-augustyn-intarea-ipref-01 - IP Addressing with References
(IPREF) (ietf.org)
And this is the associated IETF 117 slides, .
slides-117-intarea-ip-addressing-with-references-ipref-00 (ietf.org)
GENERAL POST ANALYSIS COMMENTS
At a high level, IPREF would be an additional transition
technology, that could provide an alternative mechanism for
organizations seeking to deploy IPv6, but needs to be compared in
actually operation with existing TTs.
This is accomplished through the use of several key components,
including:
IPREF Gateways (IGs), which need to be present at each end &
site for all sessions utilizing IPREF.
The platforms the IGs run upon is not clearly established
at this time, but could be upon standalone OSs (e.g Linux, Windows,
etc.), in existing Edge Routers (vendors not yet approached), Proxies,
or in other platforms, to be defined.
1. Should IPREF move forward at IETF, this is an important topic to
be discussed.
The IGs will communicate and transport end host sessions
seamlessly, across any IP network, using a new IP header field called
Reference.
This would obviously require action at the IETF, to
determine the viability and timing for adding such a new field, to both
V6 and V4.
The IGs would learn about the new “Reference” field addresses,
by querying (to be developed) AA records at DNS servers.
The AA records would return addresses that contain the
destination site address, which would include an unique IP Address and
Reference number pair.
This would obviously require action at the IETF, to
determine the viability and timing for adding such new capability to DNS.
As a potential (interim) alternative, the IPREF number pair
could be added in DNS as a TXT record.
To facilitate all the above, a new, separate/additional “Local
DNS Resolver” would be required at all sites supporting IPREF and paired
with an IG. This Local Resolver would need to be the first resolver for
all hosts that could utilize IPREF and has logic that would both
understand AA records and Reference Field values. The “Local DNS
Resolver” would also need to contain logic that communicates with the
local IG to create and utilize IPREF mapping tables.
In general, IPREF seems well thought out, has some strengths
and has the potential to accommodate many of the use cases we
discussed. The challenge will be the reaction from IETF regarding the
viability and timing of adding new fields and capabilities to core
functions, such as IP Headers and DNS operations. Also, IETF needs
to react to the value of developing and providing a new Transition
Technology, beyond those that are available and in operation today.
One final concern is what vendors may be interested in adding a new
technology & function to their platform(s).
ADDITIONAL INFORMATION AND COMMENTS REGARDING IPREF
IPREF Uses reference values to address locations, between IPREF
gateways, in addition to the IP Addresses.
The new field in IP header is called Reference and there is a
+700 in the examples.
An IPREF GW (IG) must be installed at every site needing to use
IPREF. The GWs will communicate using v4 or v6 across the Internet or
other IP network(s).
The IG would be a new box in the network or data center or could
be added in existing devices such as an Edge router. The author has
not yet approached router, proxy or other vendors, at this time. If
IPREF can gain support at the IETF, vendors may be inclined to pay
greater attention.
IPREF addresses are used only between Gateways (IGs), over any IP
network. These sessions can be v4 or v6.
The new IPREF “Local DNS resolver” is required with every GW and
for every host potentially using IPREF. For this to function
optimally, in existing production networks, it will likely be necessary
to put this DNS server first in resolv.conf type lists. That could be a
large # of queries and a potential scalability & performance issue. May
also be an architectural consideration for those using multi layer (e.g.
Split) DNS configurations. Operators would also need to determine how
to optimally define resolv.conf and other IPAM definitions, for all
existing DNS layers to work cohesively with the new IPREF Local DNS
resolver.
How many IGs are necessary? One GW for each site or city, or
……… Good estimate is to use the number of Edge routers. May turn out
to be kind of a per city or per major location basis. Need to evaluate
further. Situations and networks may vary.
The IPREF local DNS will return a local (e.g. Private) address to
the requesting client, after determining that this session will be using
IPREF. This process also needs to be evaluated in more detail. But
the requesting client(s) does not need to be aware that IPREF even exists.
Would IPREF have a negative side effect of allowing enterprises to
further delay using v6? Possibly, but only in their internal network
and thus only affecting their own internal traffic and facilities. It
should facilitate the use of IPv6 for inter connected networks, such as
the Internet.
However, as previously alluded to, there are a great number of
changes required to make IPRef work. It is not clear how the system
will operate in a production network. That is, it is not clear what is
statically configured in the IPRef proxy and what is defined in DNS. It
also appears that the IPRef proxy, at times, dynamically changes
configuration. This is not likely to be looked on favorably in critical
networks, for example, those run by the financial industry. It is not
clear how IPRef will work with firewalls, load balancers and other
middleboxes which are common in enterprise networks.
POST MEETING COMMENT FROM NALINI. IPRef is far from obvious in
its functioning. It will likely not be easy for enterprise personnel to
learn. One of the members of our team, after spending two hours of
presentations and questions, is still not clear on how exactly IPRef is
configured. It is not likely that enterprises will have the patience to
spend that much time learning a new protocol.
POST MEETING COMMENT FROM WALDEMAR. Nalini's comment on
experiencing difficulties increasing share of IPv6 beyond 60% led to a
discussion how IPREF can help with breaking through it. Waldemar pointed
out that existing TT's perpetuate IPv4 and thus will never be able to
eliminate IPv4 "won't be able to kill the beast". IPREF does not rely on
IPv4, it takes away IPv4 early in the process, requires far lower
commitments from the users which will break the resistance. [In fact I
have further thoughts on the subject, and some good ideas. I am rather
confident IPREF will eliminate IPv4 Internet and much sooner that
anything else].
SPECIFIC QUESTIONS AND ANSWERS.
Having multiple/manifold gateways could be an issue. May
require MANY of them, depending on how many partners or external sites
you may have. This could be a support and admin issue for some
organizations.
Monitoring performance and network management of these new
platforms, may also be important issues. How will these extra hops
and additional processing effect both categories?
If IPREF works as well as envisioned, could this delay the
deployment of IPv6, at many organizations? Possibly but should only
affect their own internal networks, for the most part and these orgs may
even appreciate the flexibility.
Transition technology and IPv6 deployment timing could be an
issue. By the time protocol changes are designed and implemented, will
IPv6 be deployed to the extent that a new TT will be of value? WE
FEEL THIS IS A SOMETHING THE IETF SHOULD CONSIDER AND DETERMINE.
However. In a post meeting email comment, Waldermar expressed concern
that this is something the IETF should consider. “ I actually strongly
disagree with the comment. IETF is not to try to guess what the future
brings.”
Could there be embedded base issues after IPv6 deployment has
progressed and the world is predominantly IPv6 only, obviates the need
for IPREF?
There seem to be manifold potential Use Cases for IPREF, as a
transition technology. Is IPREF is superior to other TTs, such as
464XLAT and NAT64? Why? THERE IS A LIST OF WHY IPREF IS
SUPERIOR, IN THE IPREF DOC. SOME EXAMPLES ARE: WORKS WITH DNSSEC. CAN
DROP IPV4 INTERNET EARLY. HUGE COST SAVINGS BY DELAYING UPGRADING
INFRASTRUCTURE TO ALL IPV6 IMMEDIATELY. IPREF OBVIATES THE NEED FOR
DUAL STACK.
In order to implement and fully utilize IPREF a new DNS record
type (AA), would need to be standardized and deployed. Do you feel this
will be well received by IETF and if so, how long before this could be
deployed in production networks, throughout the world? THIS QUESTION
NOT ADDRESSED IN GREAT DETAIL, BUT COULD BE A FACTOR AND SHOULD BE
ADDRESSED AND CONCLUDED AT IETF.
In order to implement and fully utilize IPREF, a new field
needs to be added to IP Headers. This is also a significant
required change. Do you feel this will be well received by IETF
and if so, how long before this could be deployed in production
networks, throughout the world? THIS AREA IS HIGHLY DEPENDANT UPON
THE REACTION OF IETF TO IPREF AND EXACTLY HOW AND WHEN THE “REFERENCE”
FIELD COULD BE ADDED. THIS MAY EVEN BE A USE FOR EHs.
IPREF Uses reference values to address locations, between IPREF
gateways, in addition to the IP Addresses. Could this added
complexity be a challenge for enterprises, in your opinion? YES.
NEW FIELDS, FLOWS, DNS RECORDS. NEW PLATFORMS? WALDEMAR SUGGESTS
ONE BENEFIT IS TO IMPROVE NAT TRAVERSAL, WHICH IS IMPORTANT AND
VALUABLE AND ALONG WITH OTHER POTENTIAL BENEFITS, MAY BE WORTH THE EXTRA
COMPLEXITY.
An IPREF GW must be installed at every site needing to use
IPREF. The GWs will communicate using v4 or v6 across the Internet or
other IP network(s). Is this true that the GWs can use both
protocols? Are they equal or will one work better than the other?
Why? DID NOT ADDRESS THIS QUESTION IN GREAT DETAIL BUT MOST USE CASES
LEAN TOWARDS USING V6 BETWEEN IGs.
The IPREF GWs are new boxes in networks or can be added
devices such as an Edge router. What platforms has IPREF GW been
tested on to date? What is planned? NOT ADDRESSED AT THIS TIME.
New local DNS resolver required with every GW location. Not
sure if this will work if you do not put this DNS server first in the
resolver lists. That could be a large # of queries and a potential
scalability & performance issue. Would also need to determine how to
optimally define resolv.conf and other IPAM definitions for all existing
DNS layers to work cohesively with the new local IPREF DNS resolver.
Would we expect IPREF to function cohesively with integrated DDI
solutions, such as INFOBLOX and BLUECAT? NOT ADDRESSED AT THIS
TIME.
Questions when multiple addresses are returned. V4, v6 and
IPREFs. And how this might work with Happy Eyeballs. How would
this work and how would enterprises control this? Are facilities
like GAI.CONF effective with IPREF? MORE ANALYSIS REQUIRED IN
THIS AREA BUT WALDEMAR PROVIDED SOME RELATED COMMENTS IN AN EMAIL
RESPONSE, WHICH IS BELOW IN BLUE TEXT.
It never occurred to me that IPv4 Internet could serve as a backup
to a flaky IPv6 Internet. This question makes me think, there could be
an optional feature to perform a backup switchover.
To answer the question, the host would get two, or possibly more
equivalent addresses. With IPREF, there is no dual stacks, so it would
be either native addresses matching local network protocol or IPREF
addresses. The IPREF ones would appear as local private addresses. The
host wouldn't know which ones would go over which Internet but it
probably does not need to know that. It can probe them all and pick the
best one. Since IPREF addresses would be on a particular private subnet,
gai.conf could be used to prefer them over native ones or the other way
around.
What's interesting, the gateway could do that, too. Because the
resolver asks the gateway for mapping, the gateway knows the presented
addresses are equivalent. So, it could conceivably select one on behalf
of hosts. That way it could aggregate probing to the same destination.
I'm not sure if that would be useful but potential exists.
The IPREF local DNS will return a local address to the
requesting client, after determining that this session will be using
IPREF. THE LOCAL DNS ALSO COMMUNICATES WITH THE IG TO KEEP IPREF
MAPPING TABLES UP TO DATE.
Why not use a regular proxy. Would that not be less
engineering and complexity? PROXY CANNOT TRAVERSE NAT. CANNOT COME
IN V4 AND GO OUT V6.
How is IPREF stateless ? BASED ON LOOKUP AND MAPPING TABLES
IN IGs. LOCALS HOSTS DO DNS RESOLUTION, IGs DO NOT. IGs ACCESS
THE AA RECORD TYPES IN DNS. OR USE TXT RECORD IN DNS, UNTIL AA RECORD
TYPES ARE AVAILABLE. A BIT OF A HACK BUT TXT SHOULD WORK.
********** BACKUP SCENARIOS NEED TO BE ADDRESSED. SPECIAL MAPPING
NEEDS TO BE SETUP. HOT STANDBY AND CLUSTERS AND MULTI HOMING LOGIC
NEEDS TO BE BUILT INTO THE IGs WALDEMAR FEELS THE WG SHOULD ADDRESS
THIS. WHICH WG IS A QUESTION. POSSIBILITIES INCLUDE INTAREA AND 6MAN.
What about diagnostics and network management between the GW’s
and on the GW’s themselves. What do these packet flows look like?
Are new tools required to manage the GW’s? Will existing tools support
the GW’s? MORE ANALYSIS REQUIRED.
What about scaling. What platform, os, etc. How to tune and
optimize. How big based on the number of sessions or other
factors? MORE ANALYSIS REQUIRED.
Will routing change? Also several questions in this area,
including potential effects on routing protocols and routing
performance. NO CHANGES SHOULD BE REQUIRED. ROUTING WILL WORK AS
IS AND ROUTERS WILL NOT PROCESS REFERENECE NUMBERS. DEFAULT ROUTES NEED
BE DEFINED TO GET END HOSTS TO THE IGs.
Will there need to be a global DB for Reference numbers? Who
will do this (e.g. IANA?)? Will these numbers need to be tied to
registered IP Addresses in any way? WALDEMAR SAYS THIS IS NOT
NECESSARY. ALLOCATED BY LOCAL ADMINS. SHOULD BE UNIQUE WHEN
COUPLED WITH IP ADDRESS. WHAT ABOUT ANYCAST? NEED FOLLOW UP.
Will there be any specific challenges with IPREF being deployed
at Clouds, CDN’s or other off site processors. MORE ANALYSIS REQUIRED.
Once again, hopefully the above addresses the initial outstanding
issues regarding IPREF and we await reaction from the pertinent AD’s
before proceeding.
Thanks again!
Nalini, Waldemar and Mike.
The information contained in this communication is highly confidential
and is intended solely for the use of the individual(s) to whom this
communication is directed. If you are not the intended recipient, you
are hereby notified that any viewing, copying, disclosure or
distribution of this information is prohibited. Please notify the
sender, by electronic mail or telephone, of any unintended receipt and
delete the original message without making any copies.
Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
nonprofit corporations and independent licensees of the Blue Cross and
Blue Shield Association.
This message was secured by Zix®.
On 10/2/23 21:52, waldemar wrote:
Hi Everyone,
I have recently release a new version of the IPREF draft. This version
is substantially rewritten to make it easier to understand how it
works and what it can be used for. The use of IPREF for transitioning
to IPv6 is described in great detail in a dedicated section. It
describes the transitioning process and its advantages vs traditional
approach. Chiefly among them is no need for IPv4 addresses (no dual
stacks, no NAT64) which allows to drop IPv4 Internet early in the
process rather than at the very end.
Waldemar Augustyn
A new version of Internet-Draft draft-augustyn-intarea-ipref-02.txt
has been
successfully submitted by Waldemar Augustyn and posted to the
IETF repository.
Name: draft-augustyn-intarea-ipref
Revision: 02
Title: IP Addressing with References (IPREF)
Date: 2023-09-25
Group: Individual Submission
Pages: 22
URL: https://www.ietf.org/archive/id/draft-augustyn-intarea-ipref-02.txt
Status: https://datatracker.ietf.org/doc/draft-augustyn-intarea-ipref/
HTML:
https://www.ietf.org/archive/id/draft-augustyn-intarea-ipref-02.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-augustyn-intarea-ipref
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-augustyn-intarea-ipref-02
Abstract:
IP addressing with references, or IPREF for short, is a method for
end-to-end communication across different address spaces normally not
reachable through native means. IPREF uses references to addresses
instead of real addresses. It allows to reach across NAT/NAT6 and
across protocols IPv4/IPv6. It is a pure layer 3 addressing feature
that works with existing network protocols.
IPREF forms addresses made of context addresses and references.
These addresses are publishable in Domain Name System (DNS). Any
host in any address space, including behind NAT/NAT6 or employing
different protocol IPv4/IPv6, may publish its services in DNS. These
services will be reachable from any address space, including those
running different protocol IPv4/IPv6 or behind NAT/NAT6, provided
both ends support IPREF.
IPREF is especially useful for transitioning to IPv6.
The IETF Secretariat
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
