Subject: [BEHAVE] about draft-baker-behave-v4v6-framework-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 31 Oct 2008 12:23:15 +0100

Hi Fred,

I have read the document and I have some comments, see below

I am sorry if the comments do no provide the text needed in many cases, 
but if we agree on the issues, i can do that later on

I think i agree with the draft on the fundamental things.
The main thing i need we still need to converge is to some common 
terminology about the scenarios and the cases covered. I don't think 
this is a big issue, but likely to be hairy.

regards, marcelo

In section 1 the draft reads:

   The question arises: what if that is infeasible due to the time
   available to deploy or other considerations?  What if the process of
   moving a network and its components or customers is starting too late
   for contract cycles to effect IPv6 turn-up on important parts at a
   point where it becomes uneconomical to deploy global IPv4 addresses
   in new services?  How does one continue to deploy new services
   without balkanizing the network?

I find the all the introduction very clear until we reach this part.

I understand that what we want to say here is that something has changed.
The proposed approach didn't happened in the expected time frame and the 
result is that most of the Internet is still IPv4 only. Now the problem 
is that we are running out of IPv4 addresses. This means that some 
networks will need to be IPv6 only because they don't have enough 
addresses. And some other networks, while they do have IPv4 addresses 
for today's needs, they expect to run short of IPv4 address sometime in 
the future. So, for these (and other reasons), some networks are 
deciding to use an IPv6 only model.
So, we need a mechanism to allow these two worlds to communicate.

In section 1.3

   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.  Ideally, this is stateless; especially in a carrier
      infrastructure, the preponderance of accesses will be to servers,
      and this optimizes access to them.  However, a stateful algorithm
      is acceptable if the complexity is minimized and a stateless
      algorithm cannot be constructed.

I think that in this case, we should include the following sentence

In the case of client-server applications, since most of the content is 
available in IPv4 only servers, the IPv6->IPv4 direction is a stronger 
requirement.

then it reads:

      In the case of
      infrastructure applications, which know nothing of choosing among
      peers by reputation, the IPv4->IPv6 direction is a stronger
      requirement.

I don't understand this, could you explain?

      Peer to peer file exchange applications, however,
      may be more forgiving - it may well be adequate to make a subset
      of IPv4->IPv6 connections work instead of all.  (EDITOR'S NOTE: I
      would be very interested in comments on this assertion)

That i don't agree
In the p2p file sharing it is critical that everyone can connect to 
everyone, since every node is a potential peer. So why do you say that a 
subset would be ok?

I mean i would like to be able to use any computer at my house to run 
vuze, what's wrong with that?

Later on it reads:

We would very much prefer that any software
   changes be confined to the translator.

I agree with that.
However, it is a tradeoff right.
I mean, consider the case of NATPT vs NAT64/DNS64. NATPT does all in a 
single box, so according to the criteria mentioned above, it would be 
better than NAT64/DNS64, since DNS64 is located int he DNS server rather 
than in the NATPT box.
However, the price for that is to have the NATPT box tweaking your dns 
messages, which is very bad.
So, i would somehow moderate the previous assertion.

I would rephrase the whole paragraph:

   The deployability arguments bring us in the direction of hidden state:
   if state must be shared between the application and the translator or
   between translation components, deployment issues are
   greatly magnified.  However, adding the translation support to the 
affected
devices would result in architecturally cleaner approach. There is then 
a trade-off
between deployability and architectural cleanness. While an approach 
where any software
   changes be confined to the translator would achieve maximum 
deployability, the negative
impact on the architecture can be important, so it may be worth to adopt 
mechanisms that
affect additional elements.

or something in these lines....

Later on in section 1.5.  Expected uses of translation

   There are several potential uses of translation.  They are all easily
   described in terms of "interoperation between a set of systems that
   only communicate using IPv4 and a set of systems that only
   communicate using IPv6", but the differences at a detail level make
   them interesting.  At minimum, these include:

   o  Connection of IPv4-only islands to an IPv6-only network

   o  Connection of IPv6-only islands to an IPv4-only network

   o  Connecting IPv4-only devices with IPv6-only devices regardless of
      network type

   o  Connections between IPv4-only networks and IPv6-only networks,
      especially as a service within a large network such as an
      enterprise or ISP network or between peer networks.

I think it would be important to have a uniform terminology for the 
scenarios, including the scenarios document, the charter, the framework 
and the solution documents.
I really don't care which one we use, but i think we need to use only one.
I think the one in the charter is good i.e.

1. An IPv6 network to IPv4 Internet, i.e. perform translation between
IPv4 and IPv6 for packets in uni- or bi-directional flows that are
initiated from an IPv6 host towards an IPv4 host. The translator
function is intended to service a specific IPv6 network of arbitary
size. Port translation is necessary on the IPv4 side for efficient
IPv4 address usage.

2. IPv6 Internet to an IPv4 network, i.e. perform translation between
IPv4 and IPv6 for packets in uni- or bi-directional flows that are
initiated from an IPv6 host towards an IPv4 host. The translator
function services is intended to service a specific IPv4 network
using either private or public IPv4 addresses. Because this scenario
has different constraints compared to (1), e.g. the IPv4 hosts that
are to be reachable over IPv6 can be enumerated. The WG should
attempt to design a simpler solution with less impact on
applications.

3. An IPv4 network to IPv6 Internet, i.e. perform translation between
IPv4 and IPv6 for packets in uni- or bi-directional flows that are
initiated from an IPv4 host towards an IPv6 host. The translator
function is intended to service a specific IPv4 network using either
public or private IPv4 address space.

4. IPv4 Internet to an IPv6 network, i.e. perform translation between
IPv4 and IPv6 for packets in uni- or bi-directional flows that are
initiated from an IPv4 host towards an IPv6 host. The translator
function is intended to service a specific IPv6 network where
selected IPv6 hosts and services are to be reachable.

I guess this doesn't cover all the cases you want to describe, so 
probably we need to agree in the terminology for these other cases, but 
at least the cases that are covered in the charter should have the same 
name imho

So, in section 1.5.1.  Connection of IPv4-only islands to an IPv6-only 
network

imho, one key aspect that needs to be taken into account when 
considering the different cases is which sides initiates the 
communication. this is not clearly contained in the section imho.
For instance, the title seems to imply that communications are started 
from the IPv4 side, but then we have the following text

   In the first case, Figure 1, one might have a pool of equipment
   (printers, perhaps) that is IPv4-capable, but either the network it
   serves or some equipment in that network is IPv6-only.  One pools the
   IPv4-only devices behind a translator, which enables IPv6-only
   systems to connect to the IPv4-only equipment.  If the network is
   dual stack and only some of the equipment is IPv6-only, the
   translator should be a function of a router, and the router should
   provide normal IPv4 routing services as well as IPv6->IPv4
   translation.

I understand that what you mean is that the translator should support 
communications initiated from the IPv6 side (i mean, the translator must 
translate packets on both directions, the problem is in which direction 
flies the first packet, so state is created if needed, right)

In section 2-Framework it reads

   o  The functional components of a translation solution, which include

      *  A DNS Application Layer Gateway,

      *  An optional stateless translator, and

      *  An optional stateful translator.

I think the DNSALG should also read An optional DNS Application Layer 
Gateway, (see below... i don't consider the case of having manually 
configured RR with mapped addresses a case of DNS translator)

Later on in 2.2.1.  DNS Application Layer Gateway

   [DNS] describes the mechanisms by which a DNS Translator is intended
   to operate.  It is designed to operate on the basis of known but
   fixed state: the resource records, and therefore the names and
   addresses, that it translates are known to the network outside of the
   translator, but the process of serving them to applications does not
   interact with the translator in any way.

In addition to that, the DNS translator needs to know the LIR prefix

   There are at least three possible implementations of a DNS
   Translator:

   Static records:  One could literally program DNS with corresponding A
      and AAAA records.  This is most appropriate for stub services such
      as access to a legacy printer pool.

one could challenge if this is a DNS translator at all, i guess. I mean, 
i understand that in this case the DNS admin has manually created RR 
that contain the mapped addresses so there is no need to actually do 
anyhting special when handling the dns messages, right?
(well thinking about it, i don't consider this to be a DNS translator, 
so that is why i think the DNS translator is optional)

later on it reads:

   Static or Dynamic Translation of Dynamic DNS records:  In Dynamic DNS
      usage, a system could potentially report the translation of a name
      using a Mapped IPv4 Address, or using both a Mapped IPv4 Address
      and some other address.  The DNS translator has several options;
      it could store a AAAA record for the Mapped IPv4 Address and
      depend on translation of that for A records inline, it could store
      both an A and a AAAA record, or (when there is another IPv6
      address as well which is stored as the AAAA record) it could store
      only the A record.

I am not sure i understand what you mean here
When Dyn DNS updates are used imho we have two options. Either we 
synthesize the RR upon the reception of the Dyn DNS update or we 
synthesize the AAAA RR when the DNS query for that RR arrives.
Each has pros and cons but imho only the second one is related to 
DNSALG, since the first one basically means another way of populating 
the dns zone.

Later on
2.2.2.  Stateless Translation - mapped addresses

   [XLAT] describes and defines the behavior of a stateless translator.
   This is an optional facility; one could implement or deploy only the
   stateful mode described in Section 2.2.3.  Stateless translation
   enables IPv4-only clients and peers to initiate connections to IPv6-
   only servers or peers equipped with Mapped IPv4 Addresses, as
   described in Figure 3.

I understand that the stateless case also support IPv6 nodes initiating 
communications to IPv4 nodes, right?
This should be explicitly stated imho

2.2.3.  Stateful translation - unmapped IPv6 address

   [XLAT] also describes and defines the behavior of the data plane
   component of a stateful translator.  [I-D.bagnulo-behave-nat64]
   describes the management of the state tables necessitated by stateful
   translation.  Like stateful translation, this is an optional
   facility; one could implement or deploy only the stateful mode
   described in Section 2.2.2.  Stateful

I think this last sentence should read:

Like stateless translation, this is an optional
   facility; one could implement or deploy only the stateless mode
   described in Section 2.2.2.

later on

4.  Security Considerations

   One "security" issue has been raised, with an address format that was
   considered and rejected for that reason.  At this point, the editor
   knows of no other security issues raised by the address format that
   are not already applicable to the addressing architecture in general.

well, i guess we should mention DNSSEC and IPSec at least here.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave