Subject: [BEHAVE] Some Remarks on the BIH (draft-ietf-behave-v4v6-bih)

From: Ala Hamarsheh <[email-masked]>
Date: Tue, 09 Nov 2010 10:41:21 +0100

Hello all,

We have been comparing draft-ietf-behave-v4v6-bih-01 (BIH) that has been
submitted with our recent proposal draft-hamarsheh-behave-biav2-03
which proposes a generalised version of the original "Bump-in-the API" (BIA).

The first proposes a generalised combination of the original "Bump-in-the-API"
and "Bump-in-the-Stack" (BIS), and is targeted at providing support for
IPv4 only applications over IPV6 only connectivity.
The latter is an generalisation of the original BIA (only) but aimed at a complete
decoupling of the application layer from the underlying
IPv4/IPv6 connectivity and allows also IPv6 only applications over IPv4 only
connectivity.

If we ignore the BIS part in the first, and the IPv6 only application over
IPv4 only connectivity support in the latter, both drafts are very similar.

We have been analysing the BIH specification, and have some remarks.

**********
PAGE 4
**********

"1.  Introduction

   While IPv6 support is being widely introduced throughout the
   Internet,"

Hmmmm... introduced yes, but USED only very marginally (certainly in the context
of residential users)

   "a class of applications are going to remain IPv4-only.
   This document describes a Bump-in-the-Host (BIH), successor and
   combination of Bump-in-the-Stack (BIS) [RFC2767] and Bump-in-the-API
   (BIA) [RFC3338] technologies, which enables accommodation of
   significant set of the legacy IPv4-only applications in the IPv6-
   world.

   Bump-In-the-Host is not recommended to be used in double translation
   scenarios if the server is dual-stack enabled."

This last sentence is not really clear to us. What is meant by "dual-stack
enabled"? Is this dual IPv4/IPv6 connectivity? Does it mean the server application
is dual IPv4/IPv6 capable?

   "The class of IPv4-
   only applications the described host-based protocol translation
   solution provides Internet connectivity over IPv6-only network access
   includes those applications that use DNS for IP address resolution
   and that do not embed IP address literals in protocol payloads.  This
   includes essentially all DNS using legacy client-server model
   applications, which are agnostic on IP address family used by the
   destination, but not other classes of applications.  The transition
   towards IPv6-only Internet is made easier by decreasing number of key
   applications that must be updated to IPv6."

Frankly, we find that a stronger statement is needed for the whole of the
introduction. This introduction seems to suggest the proposed solution is not at
all fundamental, that it will only be needed in the future to keep on supporting
a small subset of IPv4 applications that will never be made IPv6 capable, and
hence that this solution is only needed in some exceptional cases.
It seems to turn a blind eye on one of the fundamental deadlock problems
that risks to block deployment of IPv6 forever. The vast majority of
applications today are still not IPv6 capable, certainly if one does not
only considers key communication applications such as web browsers,
email programs etc but also considers applications where communication is
only a side issue, such as for registering the product or checking for updates.
Users are certainly not going to accept switching to IPv6 only connectivity
if not about all their usual applications will continue to work as before. Likewise,
network operators will not want to force the end-users into switching to
IPv6 only connectivity against their will and risk to lose customers in the process, so they keep
their customers connected with IPv4, and have no incentive to switch to IPv6.
The result is that IPv6 deployment remains marginal which in turn results
in application developers not to bother making them IPv6 capable.
Providing dual IPv4/IPv6 connectivity would be a solution, but that actually
hardly will solve the problem. Apart of the lack of motivation of network providers
to provide this (what is the point in providing BOTH?) dual connectivity requires the ability to continue
expanding the current IPv4 operation. It takes about 5 to 10 years for any new
technology to become widely accepted (providing there are no inhibiting
factors as there certainly are for IPv6), and this will apply to IPv6 too. We probably don't have that much
time left before we run into serious problems with IPv4 expansion (predictions
about the limits of IPv4 address availability vary, but some say we are about now
at the stage of exhaustion).
A solution that allows about all IPv4 only applications to be able to communicate
over IPv6 only is hence a FUNDAMENTAL condition to break one of the blocking factors of
IPv6. So this solution is not some kind of optional functionality as the
introduction seems to suggest, BUT A FUNDAMENTAL REQUIREMENT FOR THE UNLOCKING
OF IPv6. 

*************
PAGE 8, 9, 10
************* 

   "If both A and AAAA record are available in the IPv6 only network, ENR
   does not require address mapper to assign IPv4 address, but instead
   asks address mapper to store relationship between the A and AAAA
   records, and then directly passes the received A record to the IPv4
   application.  Note: this is a scenario where a host should use
   encapsulation instead to avoid protocol translation taking place at a
   host."

We also have considered working this way, and rejected the idea. The reason is
that the view presented here on responses that both return A and AAAA records is too
simplistic. It is very well possible that the host with the A record is not
actually the same as the one with the AAAA record returned for the same name,
and even that server response from the one identified with the A record is different
from that with the AAAA record. But since the A record will not be used with IPv6 only connectivity, that hardly
matters here. More important, there is no reason why not MULTIPLE records are
returned for the name, and the DNS call should faithfully return an A record for
all the returned IP addresses to the IPv4 only application. What to be done if there are two A records returned and
three AAAA records?
The cleanest solutions is to map all the AAAA records received into A records for local
addresses, just like when there are only AAAA records returned.
There is actually no real advantage in using a different technique when there are both A and AAAA
records, as mapping still needs to be done, be it to a real instead of an internal IPv4 address.
Mapping the AAAA records instead also to local addresses also simplifies operation: no check
needs to be made for the AAAA records to see if only AAAA record(s) is (are) available or there are both
A and AAAA records. AAAA records are ALWAYS mapped to local IPv4 address A records, whatever
the situation.

The table below would have to be changed then: 

        Application | Network  | ENR behaviour
        query       | response |
        ------------+----------+---------------------
           A        |   A      |  <return A record>
           A        |   AAAA   |  <synthesize A record(s) for the AAAA record(s)>
           A        |  A/AAAA  |  <synthesize A record(s) for the AAAA record(s)>

As an option we provided the possibility for an IPv4 only application on a dual
IPv4/IPv6 connectivity machine to address BOTH the IPv4 and IPv6 servers 
(by passing both the original A records AND the to Local address mapped A records of
the AAAA records on a dual IPv4/IPv6 connectivity machine) extending
the communication capabilities of the application, but that is hardly an essential option.

   "(2) When the extension name resolver gets both an 'A' record and an
   'AAAA' record for the target host name in the IPv6 only network and
   there is no existing mapping entry for the IPv6 address.  In this case
   local IPv4 address does not need to be selected, but mapping entry
   has to be created between IPv4 and IPv6 addresses from 'A' and 'AAAA'
   records.  The IPv4 address will be returned to an application.  Note:
   this is a scenario where IPv4 communications, native or encapsulated,
   are preferred over translation."

As explained above, the section above would need to be changed to match mapping of
the AAAA records into A record(s) for local IPv4 address(es).

   "(3) When the function mapper gets a socket API function call
   triggered by received IPv6 packet and there is no existing mapping
   entry for the IPv6 source address (Editor's note: can this ever
   happen in case of client-server nature of BIH?)."

Comment to the editor's note: this can very well happen, there are actually several
situations where this can happen. The most obvious is that the SERVER application is an IPv4
only application, on a IPv6 only connectivity with a client, using BIH on the server
machine! This possibility seems to be ignored largely, but actually many server applications
today are still not IPv6 capable.

************
PAGE 15, 16
************

4.3.  IPv4 Address Pool and Mapping Table

   "The address pool consists of the private IPv4 addresses as per
   [RFC1918].  This pool can be implemented at different granularity in
   the node e.g., a single pool per node, or at some finer granularity
   such as per user or per process.  However, if a number of IPv4
   applications communicate with IPv6 hosts, the available address
   spaces may be exhausted.  As a result, it will be impossible for IPv4
   applications to communicate with IPv6 nodes.  It requires smart
   management techniques for address pool.  For example, it is desirable
   for the mapper to free the oldest entry and reuse the IPv4 address or
   IPv6 address for creating a new entry."

We proposed a similar mechanism, but it is actually not the oldest entry
that needs to be reused, but the one that was LONGEST TIME UNUSED!!!  This assumes
b.t.w. that use of address mappings needs to be time stamped, which should
be specified in the text.

   "In case of a per-node address
   mapping table, it MAY cause a larger risk of running out of address.

   The RFC1918 address space was chosen because generally legacy
   applications understand that as a private address space. A new
   dedicated address space would run a risk of not being understood by
   applications as private.

It is unclear to us what the issue is here? Why do the IPv4 only applications need
to recognise the IPv4 address as LOCAL, while they are actually trying
to communicate to a NON-LOCAL address? The whole purpose is to make the
operation TRANSPARENT to legacy IPv4 applications!
Actually, what are needed are INTERNAL addresses, not LOCAL addresses. Local
addresses are for use in a local NETWORK context. We need a range of addresses
for INTERNAL use, but that should NOT be recognised as such by the legacy IPv4 only
applications...

   "127/8 or 169.254/16 are rejected due
   possible assumptions applications may make when seeing those.The RFC1918
   addresses have a risk of conflicting with other
   interfaces.  The conflicts can be mitigated by using least commonly
   used network number of the RFC1918 address space.  Addresses from
   172.16/12 prefix are thought to be less likely to conflict than
   addresses from 10/8 or 192.168/16 spaces, hence the used IPv4
   addresses are following (Editor's comment: this is first and almost
   random proposals):

   ....

   Primary destination addresses: 172.21.80.0/20.  Address mapper will
   select destination addresses primarily out of this pool.

   Secondary destination addresses: 10.170.160.0/20.  Address mapper
   will select destination addresses out of this pool if the node has
   dual-stack connection conflicting with primary destination addresses."

We have been considering this also, and we strongly advice against it. It is
absolutely essential that NEVER should the mapped internal IPv4 addresses
conflict with IPv4 addresses being used otherwise. For one, it would almost
be impossible to debug the ensuing address conflict. The use of the primary and
secondary ranges tries to solve this problem, but it is unclear to us how BIH
would be able to recognise an address conflict in all cases in a deterministic way.
A quick poll among local network administrators shows they use exactly the same logic if they
need local address space: they look for a range that is unlikely to be used
for "standard" purposes (NAT, VPN, etc). This makes chances considerably higher
there will be a conflict.
In our opinion, asking IANA to assign and reserve a (previuosly reserved) IPv4
PUBLIC range is the the only safe solution. We have been proposing to ask
them to free up one of the few (precious) last reserved class A ranges for this
purpose, because that would ensure a very large range would be available to do
mapping if needed. Systems with limited memory or processing power would
not necessarily need have to use the whole Class A range tho. If assigning a class A range
is too tall an order, a class B range may be sufficient tho. Class C range is
definitely too small.

   "Source addresses: 172.21.112.0/30.

   Source address have to be
   allocated because applications use getsockname() calls and as in the
   BIS mode an IP address of the IPv4 interface has to be shown.  More
   than one address is allocated to allow implementation flexibility,
   e.g. for cases where a host has multiple IPv6 interfaces.  The source
   addresses are from different subnet than destination addresses to
   ensure applications do not do on-link assumptions and do enable NAT
   traversal functions."

This is true, but in this case there are provisions to have a valid source
address (internal source addresses are explicitly provided for in the IPv4
address space).

*************
PAGE 16
*************

   "DNS cache

   When BIH module shuts down, e.g. due IPv4 interface becoming
   available, BIH must flush node's DNS cache of possible locally
   generated entries."

It is not absolutely essential that address mapping are stored in non-volatile memory,
but it is highly recommended. The text probably better be adapted to include that
in the section about the address mapping mechanism.

GENERAL REMARKS
- the reference to sockets should be eliminated. While many systems use
sockets as API interface, this is not really a requirement for Internet communication.
- there is no reference made in the document about the decision process to use
the API layer translation (BIA) or the network layer translation (BIS).
Some guidelines or rules would be very welcome.
Personally we did not find any advantage of BIS over BIA and deemed including BIS
as an unnecessary complication, but we may be overlooking arguments.
- how does a host KNOW that there is only IPv6 to the peer host? At the local
side it can be known if the host has IPv4 only, IPv6 only or dual IPv4/IPv6 connectivity,
but finding out for the WHOLE path is trickier
- the English language could be improved. Some sentences are hard to read.

Kind regards,

Ala Hamarsheh, ETRO/Vrije Universiteit Brussel
Prof. Marnix Goossens, ETRO/Vrije Universiteit Brussel

---

From: <[email-masked]>
Date: Tue, 9 Nov 2010 16:40:22 +0100

> is dual IPv4/IPv6 capable?

A server and server application that could be reached via IPv4 if IPv4 access just would be available for a host.

The applicability statement text is definitely under discussion, and probably also in Behave WG meeting at Thursday.

> Frankly, we find that a stronger statement is needed for the whole of
> the introduction. 

> introduction seems to suggest, BUT A FUNDAMENTAL REQUIREMENT FOR THE

Such a solution is called dual-stack natively or via tunneling. People here, including me, have experience that not 100% applications work through protocol translators, and ALG is not feasible for every such application. 

The protocol translation can be such fundamental solution only in a scenario where subset of applications are allowed to break, can be upgraded to IPv6, or are non-existent.

I'm more than happy to hear your reasoning why protocol translation can be a fundamental solution. It would help BIH discussions:)

> We also have considered working this way, and rejected the idea.

Good catch. This is also one of my questions to Behave WG at Thursday, as I've also started to think that the A record should be synthesized also in this case (but not fully because of same reasons).

> from that with the AAAA record. 

With this I don't agree. You cannot never tell for sure whether a dual-stack host uses IPv6 or IPv4 for its communications, hence by having different *service* behind A and AAAA records of the same name you would have massive problems (it doesn't matter if the machine is different as long as the service is the same). At least I'm not aware of any non-academic use of overloading a name this way.

> all the returned IP addresses to the IPv4 only application. What to be
> done if there are two A records returned and
> three AAAA records?

This sounds sensible for me. Scrap (or don't even ask) A records in IPv6-only access, and synthesize A's based on AAAA's would then be the proposal.

>         Application | Network  | ENR behaviour

Sounds sensible for me, comments from others in this list?

> As an option we provided the possibility for an IPv4 only application

You have running code? On which platform, Linux maybe?-)

> today are still not IPv6 capable.

It is not ignored, the server scenario is purposefully left out ("host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std)").

So BIH in a way behave likes an external NAT: application can create listen sockets on its IPv4 address, but as there is no IPv6->IPv4 mapping on BIH no incoming connections get through. The application has to create direct connections in STUN/ICE style. I guess there could be ways to sort this out, but as said it is out of scope for BIH.
  
> be specified in the text.

That is fine recommendation.

> for INTERNAL use, but that should NOT be recognised as such by the

I'm not sure I got your point. The source address (e.g. address of virtual BIH interface) must be from RFC1918 so that legacy applications don't accidentally think they are NOT behind NAT. The destination address could be anything that ensures application understand it is on the other side of NAT - so that application initiates proper NAT traversal tools. However, as we don't want to consume the few public IPv4 addresses left, we thought it would be best if these destination addresses would also taken from RFC1918 space.

This is also one question I had in mind for Thrusday's behave WG meeting.
 
> would be able to recognise an address conflict in all cases in a

True. An alternative I have in mind is to just write:"BIH shall select the used source and destination addresses in a manner that does not conflict with other interfaces" and leave it up for implementations to pick initial ones, and then find a way to "renumber" or bluntly disconnect BIH sessions if suddenly a conflicting IPv4 interface appears. After disconnect the apps will reconnect, and if BIH is still required then different addresses would be used. . .  but if application tries reconnect with old IPv4 address without triggering DNS query, well, you can't have bullet proof solution with translation anyway.

> them to free up one of the few (precious) last reserved class A ranges

For source you cannot use this approach due application backward compatibility reasons, but destination addresses you could. Personally I'm fine for burning remaining IPv4 addresses, there's no (nice) future in IPv4 anyway:) I just don't think it is easy as some people might have much more productive use for those addresses.. I.e. may be cheaper to have address conflict avoidance code and rare collisions than dedicate addresses for this.

> address (internal source addresses are explicitly provided for in the

What addresses? 127.0.0.1 and 169 and so would be considered as *no internet connectivity*.

> but it is highly recommended. 

Why?

> sockets as API interface, this is not really a requirement for Internet

Those should be examples, I'll check if need for clarifications.

> as an unnecessary complication, but we may be overlooking arguments.

Implementation decision, but we can provide arguments to the spec. BIA is probably technically better option (IPv4 packets are never generated), but by definition BIA requires touching *API* (or possibly APIs). And touching API(s) may not be so trivial always. On the other hand BIS may be possible to implement as virtual interface very much like VPN.

Hence it fully depends where you are adding BIH to. Your closed system might be better off with BIA, but for your off-the-shelf linux host it may be far easier to get BIS running. And so on.

> but finding out for the WHOLE path is trickier

Very difficult. E.g. DNS responses may be lost.. That is one reason why I think existence of IPv4 address for peer in case of IPv6-only access is irrelevant for BIH.

> - the English language could be improved. Some sentences are hard to

Right, much of the text is copy-pasted from original RFCs mostly written by non-native speakers, and the updates are made by other non-native speakers like me:) Language improvement suggestions are also welcome, but let's get content first. 

Thank you very much for your thorough review and comments,

Teemu