Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios
draft-russert-rangers-05

This draft was in the IESG review a while ago. After discussion the IESG was happy with my proposed way forward, but they wanted two additional modifications:

1. Make templin-iron a normative reference. The IESG felt that draft-russert-rangers is primarily an applicability statement, and as such, the base technology should be in stable reference such as an RFC. We're assuming templin-iron is in the publication process already?

  (We note that RANGER is already RFC 5720. Perhaps that too should be a normative reference. This may also apply to some of the other components such as ISATAP.)

2. We would like Section 6 on limitations to be expanded a bit. Here's a possible rewrite by me:

  The scenarios discussed in this document have not closely examined
  future growth of the native IPv6 and IPv4 Internets independently of
  any growth in IRON/RANGER overlay networking.  For example, it is
  likely that current-day major Internet services that talk to millions
  of customers simultaenously (e.g., google, yahoo, ebay, amazon, etc.)
  will continue to be served best by native Internet routing and
  addressing rather than by overlay network arrangements that require
  dynamic mapping state coordination.  A study of the balance between
  growth in the native Internet for supporting large Internet services
  and growth in overlay networks for supporting smaller multihomed end
  user networks is topic for ongoing efforts including IRON
  [I-D.templin-iron].

  Issues related to RANGER have been discussed in Section 3.7 of
  [RFC5720]. These include effects of mapping systems to application
  traffic, the need to secure the mapping system, MTU effects, and
  the ability of legacy Internet networks to connect to those employing
  RANGER.

Can these changes be accommodated?

[Ballot discuss]
Holding a Discuss until the two remaining issues are handled.

These are:

- improve the limitations section (not completely happy with it yet)
- move the main architecture specification to a normative reference

[Ballot discuss]
Discussion point for consideration by the IESG in forming their position...

I am a little nervous about reviewing the operational scenarios for
an architecture before that architecture has been completed.

AFAICS [draft-templin-iron] is still work in progress. Although I can
review that document to understand the current intention of the
designers of the architecture, it is unclear to me how I can be sure
that the scenarios expressed here will be consistent with those
architectures when/if they are published as an RFC.

That [draft-templin-iron] is an informational reference here, means
that this I-D would not even be queued waiting for completion of the
architecture.

I see two options. Either hold this back and present it for publication
at the same time as the architecture, or recast it in terms of the
problem statement and the scenarios that need to be addressed so that
the architecture becomes a solution to this document.

The second of these options, although more work, might be more
expeditious.

Otherwise, I found this a useful explanation of the Iron Ranger work,

I was given the task of performing the RFC 5742 review of this document for the IESG. The purpose of this review is to ensure that submissions via the RFC Editor do not improperly collide with IETF working group efforts or allocate numbers from IANA spaces not designed for such use. The purpose of this review is NOT to make a technical review, or provide feedback about the general quality of the document.

I have now performed my review of the document. You can find my recommended conclusion for the IESG below, followed by some technical and editorial points that are provided just for information. The next step is that the IESG discusses my recommendation on its Thursday telechat.

********** IESG RECOMMENDATION ***********************

Recommended action for the IESG:

The IESG recommendation is conditional. If the edits below are performed then our conclusion is this:

  2. The IESG has concluded that this work is related to IETF work done
      in WGs V6OPS and LISP, but this relationship does not prevent publishing.

The required edits are:

- Section 1: Change s/Three complementary approaches/Some of the complementary approaches/

- Section 4.6.1: Change s/Early point solutions (e.g., TSP, STEP, etc.) were recommended prior to the publication of IRON, RANGER, VET and SEAL./Early point solutions (e.g., TSP, STEP, etc.) were recommended. This document suggests that IRON, RANGER, VET, and SEAL would also be suitable solutions in these networks./

- Section 4.6.2: delete last paragraph

- There should be a clear statement about the limitations of the architecture

If the edits are not performed then our conclusion is this:

  4. The IESG has concluded that this document violates IETF procedures
      for  and should therefore not be published without IETF review
      and IESG approval.

********** DETAILED COMMENTS **************************

Detailed comments below. These are for the authors and RFC-Editor's information only, their treatment is not a condition for the IESG's approval message, though of course you may want to consider them before publishing the final RFC.

As a high level comment I liked seeing the draft and I think it makes sense to publish it as a companion for earlier documents. I do have a number of question marks and some suggested changes. As noted above, there are also a few changes necessary in order to ensure that the draft does not collide with IETF work, such as changing the recommendations of an IETF RFC.

My high level issues with this work include:

(1) I am not sure the draft has enough information about the limitations of the architecture. The draft explains how it fits well in many situations, but I'm not sure it is universally applicable or free of limitations. Some of the potential issues include:

- How does a legacy device without RANGER support talk to a RANGER device deep in another network, expecting to receive packets in very specific IP version and with specific encapsulation? How does the DNS ensure that the two devices find each other?

- Address selection between multiple source address spaces (internal and external) is not trivial

- Address and/or protocol translation (Section 4.1.2) may imply that some services cannot be used or that one of the sides in the communication cannot initiate connections

- The use of nat-pt and the newer nat64 designs from behave has been described at a high level, but if you look at the details there are likely to be issues; as documented in the NAT-PT deprecation RFC it has issues, and as we know NAT64/NAT46 work in BEHAVE has focused on solvable scenarios and does not claim to be a universal translation tool

- While theoretically there may not be host changes (Section 3), in practice not all the mentioned components exist on all devices. For instance, SEAL implementations do not exist on every device today.

These issues and any others should be described somewhere in the document.

> Three complimentary
> approaches to transform Internet technology are being pursued
> concurrently within the IETF: translation (including Network Address
> Translation (NAT)), tunneling (map and encapsulate), and native IPv6
> [RFC2460] deployment.

The IETF is certainly pursuing these, but the list is by no means exhaustive or representative of the equal status of these efforts. I would suggest saying "Some of the complimentary approaches ..."

>              Figure 4: Enterprise networks and the Internet

I must say I did not grasp this figure. There is very little explanations of it. Why does the PA IPv6 allocation on the left side increase from A and A.1, but stay the same for the RFC 1918 allocations? What's the difference between PA allocation on the left side and PI registration the right side? Which networks have which addresses?

> IRON/RANGER is further compatible with a number of
> schemes intending to address routing scaling issues, including A
> Practical Transit Mapping Service (APT) [I-D.jen-apt], FIB
> Suppression with Virtual Aggregation [I-D.francis-intra-va], LISP
> [I-D.farinacci-lisp] and others.

I'm not sure what the exact definition of "compatible with" is here. I'd be surprised if you really meant that these schemes are interoperable on the wire, unless IRON/RANGER encompassed all these techniques and their detailed protocol implementations.

Perhaps you want to say "... is compatible with the concepts in a number of schemes ..." or "... compatible at the concept level ... ".

> Figure 10 shows the NAT-PT-
> equivalent translation in the VET router, and Figure 11 shows the
> BIS-equivalent translation in end systems.

What is BIS? Please expand the acronym on first use.



> This gives rise to a "nested NATs" scenario, which can
> increase the overall brittleness brought on by NAT traversal.
>
> To address this brittleness, the ISP can deploy "Carrier Grade NATs"
> (CGNs) [I-D.jiang-incremental-cgn] that provide a second level of
> RLOC address translation on the path from the CPE to the Internet.
CG will not address the brittleness. Having just one NAT would address the brittleness (e.g., in DS-Lite you only need to deploy one level of NATs).

CG alone will probably increase the brittleness, by making heavier use of the same address for more endpoints, inaccessibility of the CGN from customer control, etc.

> Scenarios and Analysis for Introducing IPv6 into ISP Networks
> [RFC4029] discusses both ISP backbone network and customer connection
> transition considerations, however this document considers router-to-
> router tunneling use cases.  Therefore the ISATAP mechanism (which
> only supports host-to-router or host-to-host tunneling) is not
> mentioned as a candidate technology.  Early point solutions (e.g.,
> TSP, STEP, etc.) were recommended prior to the publication of IRON,
> RANGER, VET and SEAL.


RFC 4029 is an IETF RFC, and the text above gives an impression that the situation has somehow changed after the publication of IRON and other documents. This is not the case, the IETF is not recommending IRON or any of the other mentioned things in any way. I would either remove the last sentence altogether or re-formulate it to: "Early point solutions (e.g., TSP, STEP, etc.) were recommended. This document suggests that IRON, RANGER, VET, and SEAL would also be suitable solutions in these networks."


> [RFC4215] provides a (dated) Analysis on IPv6 Transition in Third
> Generation Partnership Project (3GPP) Networks.  It envisions an
> extended period of support for both IPv4 and IPv6 protocols in the
> operator network.  User Equipment (UE) uses the Packet Data Protocol
> (PDP) context to establish tunnels through the operator network to a
> Gateway GPRS Support Node (GGSN).  IRON/RANGER could be used in 3GPP
> transition; when the UE uses IPv6, and the PDP context is established
> across an IPv4 provider network, the UE can configure itself as an
> EBR and contact the GGSN (as an IRON/RANGER EBG) through VET
> tunneling.
This seems incorrect. The GGSN *is* the next hop router in these networks, so if the GGSN supports IPv6 or VET you can also establish IPv6 PDP contexts. (There is a possibility of someone on purpose blocking some L3 protocols at L2, but based on experience the likelihood of this remains relatively small, even in today's IPv4-only commercial networks.) Also, the cellular networks have tunnels and the inner/outer IP versions are completely separated.

I would suggest a reformulation:

  [RFC4215] provides a (dated) Analysis on IPv6 Transition in Third
  Generation Partnership Project (3GPP) Networks.  It envisions an
  extended period of support for both IPv4 and IPv6 protocols in the
  operator network.  User Equipment (UE) uses the Packet Data Protocol
  (PDP) context to establish tunnels through the operator network to a
  Gateway GPRS Support Node (GGSN).  IRON/RANGER could be used in 3GPP
  transition; when the UE uses IPv6, and the chosen GGSN does not offer
  IPv6 service or allow the creation of IPv6 PDP contexts,
  the UE can configure itself as an
  EBR and contact a separate IRON/RANGER EBG through VET
  tunneling.


(Not that I would recommend this model either because flipping the switch in the GGSN should be the primary action, but at least it makes your text correct.)

The second paragraph in this section needs a rewrite as well, for the same reasons.

> [RFC4215] was published prior to the development of IRON, RANGER, VET
> and SEAL.  This document therefore updates RFC4215 to introduce these
> new technologies that are widely applicable to managed network
> scenarios such as cellular operator networks.

This paragraph needs to be deleted.

You cannot have someone's personal document update an IETF RFC. If you want to update that RFC, please work through a working group and build a consensus that the named techniques are something that should be brought up. However, I'll also point out that RFC 4215 is indeed very dated and perhaps the effort should be spent more wisely by writing a new document. But in a recent 3GPP-IETF workshop on IPv6, IRON, RANGET, VET, or SEAL were not mentioned as potential tools for the cellular operators.

> The ATN is currently an OSI network but is projected to transition to
> IPv6 over time.  IRON/RANGER can bridge OSI networks together across
> the IPv4 (or IPv6) Internet, or bridge IPv4 or IPv6 networks across
> an OSI network.

Where is the definition of tunnel encapsulation for IPvx over OSI? What about translation from IPvx to OSI and back? Are the referred RFCs widely implemented and complete? I suspect that many details are missing...