Subject: [BEHAVE] Review: draft-ietf-behave-v6v4-framework-04

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 Dec 2009 14:01:42 +0100

This is my review of draft-ietf-behave-v6v4-framework-04.

The document is too wordy. It needs to be edited for length. Alternatively, it could be merged with an applicability statement.

Specific remarks:

   One could - and in the 6NET we did - build an overlay
   network using the new protocol inside tunnels.

These are not equivalent. A tunnel can't make an IPv4 host talk to an IPv6 host.

They are also not opposites, as with tunneling there will still be translation in the form of IPv4 NAT because the whole point of the exercise is the lack of sufficient IPv4 addresses.

Also, not sure the "as we did" aside is appropriate in this document.

   Dual-Stack implementation:  A Dual-Stack implementation, in this
      context, comprises an IPv4/IPv6 enabled end system stack,
      applications plus routing in the network.  It implies that two
      application instances are capable of communicating using either
      IPv4 or IPv6 - they have stacks, they have addresses, and they
      have any necessary network support including routing.

I don't think this is good terminology, as "implementation" could also apply to soft- or hardware that is capabable of both protocols, but only one is actually provisioned. Note that "dual stack implementation" doesn't occur anywhere else in the document, anyway.

About the -converted and -translatable addresses: I would prefer "translator IPv4 address(es)" etc, this is more obvious.

Again, "IPv4-converted" and "IPv4-translatable addresses" don't occur outside the terminology section, and neither do "Network-Specific Prefix" or "Well-Known Prefix". Defining terminology that remains unused is a waste of the reader's time.

"Stateful translation": I think this needs to mention that multiple IPv6 hosts share a single IPv4 address, otherwise the level of abstraction is extremely high.

   applications with - any other system running the same application

This is strange. Does my web browser talk to other web browsers?

   Client/Server Application:  Per whatis.com

Could be clearer that this is a quotation. (Remember, not everyone has English as a first, second or third language.)

      program, the server, which fulfills the request."  In networking,
      the behavior of the applications

the = these? Better: client-server applications

      Examples include mail handling between an end user and his mail
      system (POP3, IMAP, and MUA->MTA SMTP), FTP

FTP doesn't belong in this list because of the active mode.

   Peer-to-Peer (P2P) Application:  A P2P application is an application
      that uses the same endpoint to initiate outgoing sessions to
      peering hosts

The term "peering host" is strange. What about "correspondent host"?

      Peer-to-peer infrastructure applications:

When people use "peer-to-peer" they are NOT talking about this kind of stuff, doing so here only confuses the issue and wastes space.

         of peers from history or by reputation.  They use the long-term
         sessions to map content availability.  Short-term sessions are
         used to exchange content.

Untrue, BitTorrent uses very short connections to the tracker, there is no ongoing long term connection. Again, unnecessary, potentially confusing detail that only takes up space.

A distinction that may be more useful (but probably too detailed here) is whether a peer must be able to connect to any given peer for the application to work (like in VoIP) or the ability of each peer to talk to a subset of all peers as long as there are some peers that can talk to all other peers (like BitTorrent) is sufficient.

   o  We need a technology that will enable systems that act as clients
      to be able to open sessions with other systems that act as
      servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6
      direction.

We do? As long as all the servers are on the IPv4 side we don't need the IPv4->IPv6 direction.

   o  We also need a technology that will allow peers to connect with
      each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6
      direction.  Again, it would be ideal if this was stateless, but a
      stateful algorithm is acceptable if the complexity is minimized
      and a stateless algorithm cannot be constructed.

   o  In many situations, hosts are purely clients.  In those
      situations, we do not need an algorithm to enable connections to
      those hosts

Huh? Which is it?

I think the second needs to be removed, we can't be in the business of giving people excuses to provide one-way connectivity. It's not the translator's place to determine whether a host needs incoming connectivity or not.

This bears a striking resemblance to this
   scenario as well

Be more explicit.

2.2.  Scenario 2: the IPv4 Internet to an IPv6 network

   This scenario is predicted to become increasingly important as the
   network administrators are under pressure to put IPv6-only servers in
   its network

There is a big difference between the general interconnection of a full IPv6 network and making available only a limited set of servers. The latter can be done with some static mappings, the former requires much more elaborate mechanisms. So this needs to be split into two different cases.

2.3.  Scenario 3: the IPv6 Internet to an IPv4 network

[...]
   The stateless translation will not work for this scenario, because an
   IPv4 network needs to communicate with all of the IPv6 Internet, not
   just a small subset, and stateless can only support a small subset.

Incorrect. We are talking about the IPv6->IPv4 direction here, which can easily be done with stateless translation. The IPv4->IPv6 direction is the problem, this is scenario 4.

2.7.  Scenario 7: the IPv6 Internet to the IPv4 Internet

[...]
   Due to the huge difference in size between the address spaces of the
   IPv4 Internet and the IPv6 Internet, there is no viable translation
   technique to handle unlimited IPv6 address translation.

Again, that's part of a different scenario.

But the authors knew that, because they repeat the same text there:

2.8.  Scenario 8: the IPv4 Internet to the IPv6 Internet

[...]
   Due to the huge difference in size between the address spaces of the
   IPv4 Internet and the IPv6 Internet, there is no viable translation
   technique to handle unlimited IPv6 address translation.

Repeating the same text is bad writing in general, and even worse here because the text doesn't apply in 2.7 but only in 2.8.

I'm missing a discussion on how the scenarios can be combined. For instance, people will likely want to combine 1 and 5 but without specifically addressing that situation that could be hard.

3.  Framework

   Having laid

Pointing back to what was said earlier in the same document adds no value but increases size, don't do it.

   [I-D.ietf-behave-dns64] and possible future documents describes

describe

   mechanisms by which a DNS translator is intended to operate.  It is
   designed to operate on the basis of known but fixed state:

No, the DNS64 doesn't maintain any state, unless that includes the translation prefix, but that isn't state, but rather, configuration. I.e., a DNS64 can reboot in the middle of a user session and apart from the delays while the DNS64 is down there is no interruption of service.

   There are at least two possible implementations of a DNS64 and DNS46:

   Static records:

No, if the records are static we're talking about a regular DNS. A DNS64 adds extra functionality on top of a regular DNS implementation that makes static records unnecessary.

   Dynamic Translation of static records

I would reserve that term for DNS46 where the records are mapped dynamically based on the availability of addresses in a pool. I would use "algorithmic translation" (no capital T) for DNS64.

   In addition, some applications require special support.  An example
   is FTP.  FTP's active mode doesn't work well across NATs 

at all

Across NATs, it
   generally uses passive mode.

FTP clients generally use passive mode

May want to add some references.

However, the designers of FTP
   inexplicably wrote different and incompatible passive mode
   implementations for IPv4 and IPv6 networks.

???

The original passive mode is incompatible with IPv6 because RFC 959 (which wasn't the first FTP spec, btw) predates RFC 1883 (the first IPv6 spec) by a decade.

EPSV is compatible with both IPv4 and IPv6 (because it only mentions a port number) but (obviously) not with implementations that stick to RFC 959 and don't implement RFC 2428.

   As a general rule, a simple operational recommendation will work
   around many application issues, which is that there should be a
   server in each domain

Domain = IP version? Unclear.

   Stateless translation can be used for Scenarios 1, 2, 5 and 6

Only if there are sufficient IPv4 addresses, in which case it would be possible to run dual stack, too. Needs to be pointed out.

   For Scenario 1, any IPv6 addresses in an IPv6 network can use
   stateful translation, however it typically only supports initiation
   from the IPv6 side (NAT64 doesn't support IPv4-initiation), and does
   not result in stable addresses that can be used in DNS, other
   protocols and applications that do not deal well with highly dynamic
   addresses.

There is no reason that the IPv4 address involved in stateful scenario 1 translation are very dynamic. If they are, ICE will not work very well.

   The FTP ALG and other documents refer to the Address Format, IP/ICMP
   Translation and Table Maintenance documents.

Actually, the FTP64 document only points to RFC 2765, xlate and xlate-stateful. The address format is not relevant to the FTP ALG.

   Currently, there are two proposed solutions for this scenario: NAT64
   [I-D.bagnulo-behave-nat64] as the stateful translation and IVI
   [I-D.xli-behave-ivi]

What about I-D.ietf-behave-v6v4-xlate?