Re: [Int-area] New Version draft-augustyn-intarea-ipref-02.txt

     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