Subject: (ngtrans) Input on draft-ietf-ngtrans-dti-00.txt

From: Jim Bound <[email-masked]>
Date: Sat, 30 Jan 1999 22:07:27 -0500

Laurent and Hossam,

>2.1 The double stack
>
>   [RFC 1933] defines a transition mechanism based on a double stack. A
>   host will either send packets in IPv4 or IPv6 depending on the
>   protocol used by the destination. The IPv4 mapped addresses allow
>   applications compiled with IPv6 system calls to talk with IPv4 only
>   applications.

Any chance we could get you to use the words dual stack or dual IP layer
instead of "double stack".

>2.2 The SIIT proposal
>
>   This proposal is similar to Network Address Translation (explained
>   later), used in IPv4 networks to exchange a private IPv4 address to a
>   public IPv4 address. It is difficult with the SIIT proposal to deal
>   with applications sending addresses (such as FTP or RTP flows). In
>   that case, some Application Level Gateways acting as proxy will be
>   required. The proposal focuses on separate IPv6 and IPv4 domains. If
>   in the IPv6 domain some equipment wants to talk with an IPv4 domain,
>   it will use an automatic IPv4 address allocation of the double stack.
>   In that case, routers will have to administrate IPv4 and IPv6 routing
>   tables.

I think our assumption for transition initially is that sites will have
to have both IPv4 and IPv6 domains.  But we can discuss?

>   Like NAT (described hereafter), this is a one way translation. It
>   means that outside IPv6 domains, IPv4 applications cannot initiate
>   communications with IPv6 hosts. The context for header translation in
>   the SIIT box can be established only when an exiting IPv6 packet
>   leaves the domain.

SIIT can process incoming IPv4 packets too.  You may want to look at
Draft 05 of SIIT.

>2.3 The NATPT Proposal
>
>   Unlike SIIT [SIIT], NAT-PT is designed to provide transparently end-
>   to-end  solutions. A pool of IPv4 addresses is used to be assigned to
>   IPv6 hosts dynamically in response to any request for packets leaving
>   one of the boundaries. These assigned addresses in turn are used to
>   transparently replace the original addresses used by IPv6 end nodes
>   and vice versa. This proposal allows translation in both ways since
>   the context inside the transition box is this time established by the
>   DNS.

Note SIIT and most proposals require a pool of IPv4 addresses, including
DTI.

>2.4 The AIIH Proposal
>
>   The AIIH proposal aims at using a combination of DHCPv6 and the DNS
>   to establish a transition between IPv6 and v4 in both directions.
>   This proposal is complementary to the NAT -PT and SIIT since it
>   focuses on topology where IPv4 and IPv6 are in the same domains.

On the contrary it is complementary to SIIT and NAT-PT because it does
permit communications with an "outside" IPv4 domain.  SIIT, NAT-PT, and
AIIH permit Intranet and Internet communications.  In fact the diagram
in AIIH depicts from Intranet across the Internet to Intranet
communications.  

So I can't see your characterization of the 3 protocols here to be
accurate on my reading of your words.
>
>>    For an IPv6 host to participate in the AIIH mechanism, it MUST have
>>   a dual IP layer, supporting both an IPv4 and IPv6 stack. When an IPv6
>>   host wants to talk with an IPv4 one, the DNS will not answer with an

Your reading into the spec here.  It states supports a dual IP layer and
the functions of IPv4 and IPv6 in the stack are provided.  But I will
check this again and if its wrong I will fix it.

>   IPv6 record but with an IPv4 one. The IPv6 will request a temporary
>   IPv4 address. Mechanisms such as DHCP are currently available to do
>   such assignment. The opposite case, where an IPv4 host wants to talk
>   with a IPv6 host is more difficult to solve since no protocol is
>   currently available to do a automatic assignation.

I give a detailed example of how an IPv4 host communicates with an IPv6
host and show the actual DNS records on the DNS servers.  A protocol is
not needed it is how DNS operates on the Internet today.  

>   In our view, there are two main drawbacks in this proposal. The
>   router must be configured both for IPv4 and IPv6 protocol and the
>   assignment of IPv4 addresses is difficult since the network topology
>   must be taken into account.

On your first drawback.  I think this is one of the benefits of AIIH and
will coincide with the transition deployment of most users IMO.  

On your second drawback.  DHCPv6 makes this quite simple with the
Reconfigure message and DHCPv6 Servers will know where DHCPv6 Clients
are via the IPv6 network, which could even be from 6over4 mechanism.

I think you have mis-characterized the three proposals and I am not even
sure why you mention them.  In most cases folks only mention others
proposals when they want to use features from them not to distract
others from them to their points.  If that was your objective?

I have included your DTI proposal with the others from Grenoble to begat
transition mechanism taxonomy discussions.  

I think your proposal will assist sites greatly once the IPv6 paradigm
is dominant for a backbone.  I also think the DTI mechanism would be
useful for IPv6 tunnel paradigms in general too.

Could you put more of the diagrams in your draft that you presented at
the Orlando meeting.

thanks
/jim