Re: [BEHAVE] New I-D: IPv4/IPv6 Translator for IPv4-Only Networks

Good start on the topic.  comments:

abstract:

 "Communication initiated into the latter direction..."  this sentence 
is confusing - if you mean "Communication initiated from the IPv4 
network..." just say that.  Also, it is not clear in the abstract 
whether communication could be initiated from the IPv6 side, and if so 
how.  That becomes clear in the body.  Suggest rewording the abstract:

This document proposes Virtual IPv6 Connectivity, a method for
   deployment in IPv4-only networks to enable communications with the
   IPv6 Internet.  Virtual IPv6 Connectivity uses IP protocol
   translation to support both incoming traffic from IPv6 to IPv4, and
   outgoing traffic from IPv4 to IPv6.  Communication initiated from the IPv4 network
   is facilitated through a DNS or DNSSEC proxy to obtain a virtual IPv4 address.  
   Communication initiated from the IPv6 Internet relies on virtual IPv6 addresses stored in the authoritative DNS server. 
   Unlike existing IPv4/IPv6 interworking techniques, which are designed 
   for deployment in IPv6 networks, Virtual IPv6 Connectivity does not
   require extra, globally unique IPv4 addresses.

introduction:

s/inavertable/inevitable

add to the justification for IPv4 based translation:  "...The 
responsibility and cost for maintaining IPv4 interoperability shifts to 
those who desire to maintain the IPv4 network when IPv6 predominates."

after the DNS proxy statement, add the same statement in the abstract 
for the IPv6 initiated case.  Maybe subtle, but I just think it is 
important to establish and reinforce that a proxy is needed ONLY for 
IPv4 initiated communication and that IPv6 initiated communication 
relies solely on "normal" DNS (with properly provisioned virtual 
addresses...)

conceptual overview:

make it clear that the prefixes and addresses used are examples - you 
have not introduced the virtual addresses yet, and the reader should not 
conclude that only 2001:DB8 or net-10 work.

There is some implication that DNS servers (recursive and authoritative) 
are maintaining virtual address mappings.  Is that true?  It looks like 
(reading ahead) the "recursive name server" in the v4 initiated case is 
actually the DNS Proxy.  Also the "authoritative DNS Server in the IPv4 
network" is an unmodified DNS server with the virtual addresses 
configured.  Maybe go back and clean up the conceptual overview to make 
it obvious which components have new/unmodified logic.  I believe you have:
1. a new box, the translator
2. a new/modified box, the DNS proxy or recursive name server (or 
"virtual IPv6 connectivity name server")
3. unmodified DNS server code with provision of virtual addresses
1 and 2 determine/maintain the virtual address mappings and send name 
resolutions to 3, or maybe 3 requires manual configuration of virtual 
addresses?

Anyway, you don't want too much detail in the conceptual overview - use 
it as an outline for the sections that follow, and in fact refer forward 
to them, e.g. "Virtual addresses (section 3.0)..."  I suggest reversing 
the first two bullets in the components to parallel the following 
sections.  It is always hard to discuss interlocked sub-topics that 
refer forward/backward to each other, but I would also recommend 
reversing sections 4 and 5 to more logically flow - define the 
addressing architecture (section 3), define the 
mapping/provisioning/discovery process (previously section 5), finally 
the flow of translation (previously section 4).  Just a suggestion.

   Virtual IPv6 Connectivity consists of three components, which
   together enable hosts in an IPv4-only network to communicate with
   remote IPv6 correspondent hosts:

   o  Virtual IP Addresses (Section 3), which represent, respectively,
      the IPv6 addresses of remote correspondent hosts to local IPv4
      hosts, and the IPv4 addresses of local hosts to remote IPv6
      correspondent hosts.

   o  IP protocol translation (Section 4), which are placed on border links of the
      IPv4-only network to translate packets exchanged with IPv6
      correspondent hosts.

   o  Provisioning and Discovery of virtual IP addresses (Section 5).

Section 4:
p. 9 "For communications initiated by a remote IPv6..."  s/actaully/actually
figure 3 and 4 sort of illustrate why I think it would be better to 
explain address discovery before the translation.  in the figure 3 
example it is a natural question - how would the IPv6 correspondent know 
the virtual IPv6 address for the IPv4 host?

Section 5: 
change the title to Provision and Discovery as it discusses both 
creation and retrieval of the mappings. 

5.1:  not clear how the virtual address 2001:DB8:ABC::a.b.c.d gets 
created in the auth name server.  it almost sounds like it maintains the 
mapping.  It should be made clear who creates the mapping (the 
translator) and how it gets provisioned in the auth name server.  In 
addition to the text changes, put this flow in fig 4.

5.2:  it seems you are discussing a modified recursive name server, i.e. 
one that has part of the code required to build "virtual IPv6 
connectivity".  identify this name server explicitly as a "virtual IPv6 
connectivity name server" which combines normal recursive name server 
plus this mapping function.

There is a big hand wave here - "The recursive DNS name server maps each 
of the correspondent host's regular IPv6 addresses onto a separate 
virtual IPv4 address in coordination with the IP protocol translator to 
which these virtual IPv4 addresses route."  That coordination is the key 
to the mapping working, especially if there is not a 1-to-1 coupling 
between protocol translator and name server, e.g. the name server could 
serve multiple translators.  Even with 1-to-1 how does the name server 
know whether/not a virtual address is available?  does the translator 
give it a range that it manages?  if an address was used in a previous 
mapping, when is it safe to recycle (i.e. the IPv4 host is no longer 
counting on it)?  The translator I worked on had an internal DNS ALG 
that did this, and restricted certain address ranges for inbound and 
outbound mappings, and knew when they timed out.

A performance nicety:  both A and AAAA queries could be sent 
simultaneously; if an A record is returned, do IPv4 pass-through; if an 
AAAA record is, create the mapping.  In the event of both, prefer IPv4.

Speaking of IPv4 pass-through - since the IPv4 host likely does not have 
a global IPv4 address, is the protocol translator or modified name 
server also doing a NAT44 for that case?  By the way, is the protocol 
translator the DHCP server for the IPv4 hosts?  Otherwise, how do the 
IPv4 hosts get their addresses?  Or is that irrelevant?

Since there could be multiple IPv4 hosts which could initiate 
communication with the same IPv6 correspondent, the discussion should be 
expanded to describe what happens when there is already a mapping in the 
name server for host.v6.net, i.e. if/when it is safe to use a previous 
mapping?  if the same mapping is used for multiple flows, how do you 
know when it is "no longer in use?"  is least recently used OK to 
recycle?  the pool of virtual IPv4 addresses is finite.

Ed J.

Christian Vogt wrote:
> Folks,
>
> at the IPv4/IPv6 co-existence interim, Alain and I had sketched a
> translation-based IPv4/IPv6 interworking method that, unlike other
> translation-based solution proposals, is for deployment in IPv4
> networks.  Here is now a more detailed specification of this method,
> which we call "Virtual IPv6 Connectivity for IPv4-only networks":
>
> http://tools.ietf.org/html/draft-vogt-durand-virtual-ip6-connectivity
>
> Recall from the interim:  The main advantage of Virtual IPv6
> Connectivity is that it does not require extra global IPv4 addresses.
> We hence believe that the method will be of advantage when (a) the pool
> of unallocated IPv4 addresses is exhausted, and (b) there is sufficient
> IPv6 deployment to make it worthwhile for IPv4 networks to invest into
> IPv4/IPv6 interworking.  Consequently, Virtual IPv6 Connectivity is not
> intended to replace any other solution proposal.  It is instead intended
> to complement other solution proposals in a future where the impetus to
> invest into IPv4/IPv6 interworking has shifted from the IPv6 side to the
> IPv4 side.
>
> Furthermore, Virtual IPv6 Connectivity can already today solve some of
> the key problem scenarios, namely those involving IPv6 clients and IPv4
> servers in the absence of a unique global IPv4 addresses for each
> server.  An example is scenario (4) in Mark's and Jari's analysis [1].
>
> Finally, we would like to request a presentation slot for Virtual IPv6
> Connectivity at IETF 73.  Dan and Dave, I am assuming this would be in
> the BEHAVE session, right?
>
> Thanks everybody.
>
> - Christian, for Alain and Christian
>
>
> [1] http://tools.ietf.org/html/draft-arkko-townsley-coexistence
>
>
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave