Subject: (ngtrans) DSTM comments

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Mar 2002 16:55:03 +0200 (EET)

Hi,

A few comments (first time I really read the DSTM draft), so reader 
discretion is advised...

A few very generic comments:

 - I think DSTM would be useful with manual or semi-manual configuration 
too; some sites do have enough addresses (private if need be): using 
temporary addresses would just add to the complexity.  Using temp. 
addresses is valid only if the address shortage is the only reason to 
switch to IPv6..

So I think we need to consider whether we'd like to "generalize" DSTM a 
bit more: basic operation would be rather manually configured tunnels and 
such, and additional level would provide temporary addresses, automatic 
configuration of TEP and such.

 - There are some remnants in the document which seem to indicate strong 
ties with DHCP....

 - The draft has too long lines..

--8<--
                 Dual Stack Transition Mechanism (DSTM)
 
==> This is an overly generic name, better suited for "IPv4/6 stack + 
IPv4/6 network".  I suggest s/Transition/Tunneling/, and then the 
abbreviation would stay the same.

   When DSTM is deployed in a network, an IPv4 address is allocated to a
   dual stack node if the connexion can not be established using IPv6.
 
==> s/connexion/connection/.  I'm not sure if 'connection' is the best 
word in any case, as it seems rather TCP-centric..

The exact details on how DSTM nodes
   communicate with the DSTM Server is out of the scope of this proposal
   and will be described in other documents.

==> this is rather critical part of DSTM though.. :-)

2.1 IPv6 DSTM Terminology

      DSTM Domain             The network areas on an Intranet where IPv6 
nodes
                              use DSTM to assure IPv4 communication. An 
IPv4
                              address allocation server may be deployed 
inside
                              domain to manage an IPv4 address pool. IPv4 
routi
                              access may not be maintained within a DSTM 
domain

==> s/access may not be/need not be/

      DSTM Server             A process in charge of managing the IPv4 
address
                              space that will be allocated to DSTM Nodes.

==> s/DSTM Nodes/DSTM Nodes in the DSTM Domain/.

      4over6 Tunnelling       Encapsulation of IPv4 packets over IPv6. 
Used for
                              carrying IPv4 flows from one node to another 
in a
                              DSTM Domain.

==> this description would seem to imply that there are more than two 
possible endpoints: DSTM nodes and TEP.  This may imply e.g. shortcuts 
between two DSTM nodes in the same domain, which is not the case.  

      DSTM Client             A process on a DSTM Node who manages
                              the temporary IPv4 address allocated by the
                              DSTM Server.

==> s/who/which/

2.2 Specification Language

      In this document, several words are used to signify the requirements
      of the specification, in accordance with RFC 2119 [4]. These words
      are often capitalized.

         MUST          This word, or the adjective "required", means that
                       the definition is an absolute requirement of the
                       specification.
[...]

==> plain reference should be enough, no need to copy these.  In the other 
hand, if there aren't copied, there should be really strong justification 
from varying from "standard" keywords.

3. DSTM Overview and Assumptions

   DSTM, as discussed in the introduction, is a method that uses
   existing protocols.  This document does not specify a new protocol.
   However, DSTM defines node, server and TEP behaviours as well as the
   properties of the temporary addresses allocation mechanism.

==> client-server communication is kind-of new protocol, but it wasn't 
specified here..

   The motivation for DSTM is to provide IPv6 hosts a means to acquire
   an IPv4 address, for communications with IPv4-only hosts or through
   IPv4 applications.

==> s/through/using/ ?

   The core assumption within this mechanism is that it is totally
   transparent to applications, 

==> better say:

   The core assumption is that the mechanism is totally
   transparent to applications,

     which can continue to work with IPv4
   addresses. It is also transparent to the network, where only IPv6

==> 'which' refers to applications, but that wasn't 100% obvious at the 
first read.  Perhaps a rephrasing would be good.

     - A DSTM domain is within an Intranet not on the Internet.

==> "on" the Internet? (remove on?)

     - The temporary IPv4 address allocation is performed by the DSTM 
server.
       Different protocols (DHCPv6 being the logical choice) can be used
       for the allocation process. Native IPv6 communication between 
server and
       client is one restriction in this matter.

==> I don't understand what you mean by the restriction.

     - As an extension to the address allocation process, the DSTM server 
may a
       provide a range of port numbers to be used by the client. This 
would all
       the use of the same IPv4 address by several DSTM nodes at the same 
time,
       reducing the size of the required IPv4 address pool.

==> Remove this completely: it's an extension, and IMO not even a good
(=reliable, robust)  one.  If someone wants this, they can red it in the
other draft.

     - Once an IPv6 node has obtained an IPv4 address (and maybe a port 
range),
       4over6 tunnelling is used to forward packets from the node to a 
DSTM TEP
       where the packet is decapsulated and forwarded using IPv4. As part 
of th
       address allocation process, the DSTM server SHOULD provide the 
client wi
       the IPv6 address of the TEP to be used.

==> port range..
==> Static configuration of TEP (as mentioned in 4.4) ?

4.1 Configuration of the IPv4 stack

   As long as communications can take place in native IPv6, no IPv4
   address is given to the DSTM node. The host can detect the need of an
   IPv4 address by different methods: when a query to the DNS resolver
   results in an IPv4 destination address, when an application opens an
   IPv4 socket, or when an IPv4 packet is sent to the kernel and no
   interface is ready to forward that packet.

==> some of these mechanisms could cause extreme trigger-happiness: would 
you like a query with dig(1) trigger this?

To get DSTM robust, I think this should be considered in more detail, not 
left for implementors only.

   When the first IPv4 packet needs to be sent, the DSTM client MUST
   contact the DSTM server. This document does not specify any
   particular mechanism for DSTM client/server communication. Following
   this message exchange, the client obtains from the server a temporary
   IPv4 address as well as the IPv6 address of a TEP. If allowed by the
   implementation, the server MAY also provide the port range to be
   used. This information is used to configure the 4over6 interface. It
   is at this point that the IPv4 stack is configured.

==> MUST is a strong word here, especially as this communication is not
specified in this document and conflicts with static configuration,
besides.

==> "obtains from the server" .. I'd be more flexible than that; why would 
one have to get TEP from the server?

==> "as well as the IPv6 address of a TEP", ditto.

==> Big note: how does Client obtain the address of the Server?

4.3 DSTM processing of IPv4 packets

   When a DSTM Node needs to send an IPv4 packet, it is sent to the
   4over6 interface. If the 4over6 interface is not configured (it does
   not have an IPv4 address), the process SHOULD be blocked and the DSTM
   Server SHOULD be contacted to get a temporary address. Once an
   address is allocated, it is used as the IPv4 source address for all
   the packets leaving the interface.  The other fields of the IPv4
   packet are normally filled.

==> perhaps the term blocking should be elaborated a bit more.

   The IPv6 address of the TEP SHOULD be provided by the DSTM server
   when the DSTM node receives a temporary IPv4 address (section 5).
   However, a DSTM node MAY manually configure the TEP during early
   deployment of DSTM. This will not scale and is not recommended as a
   long term transition solution.

==> I'm not so sure about the last sentence there.  It's a local problem.  
The address could even be obtained from DNS, no big deal then.  Even 
site-local addresses could be used.

5. DSTM Server Requirements

   The DSTM server is in charge of the temporary IPv4 address
   allocation. This allocation is very simple since there is no
   localization purpose in this address. The DSTM server has just to
   guarantee the uniqueness of the IPv4 address for a period of time. To
   reduce the need of IPv4 addresses, some implementations MAY include a
   port range as part of the allocation process. This would allow the
   use of the same IPv4 address by several nodes simultaneously.

==> DSTM ports again..

   The DTSM server MUST memorize the mapping between the IPv6 address of
   the node requesting an address and the allocated IPv4 address. The
   IPv4 address is allocated by the server for a fixed amount of time.
   This duration MUST be included in the response. If the client needs
   the IPv4 address for a longer period of time, the client MUST renew
   the lease.

==> Strong words, again.  How does this remind me of DHCP..

   The DSTM server MAY allocate a temporary IPv4 address without a
   request from he client.
 
==> to whom?  for what?  how would that work?

6. Applicability Statement
[...]
   The exact capacities of the 4over6 tunnelling interface required by
   DSTM is implementation defined. Optionally, it is allowed that DSTM
   nodes configure manually (in a static manner) the tunnel to the TEP;
   but the recommendation is not to do this. The dynamic configuration
   of 4over6 interfaces as a result of the address allocation process is
   the right way to execute DSTM on an IPv6 Network.

==> the last sentence.  Who are we to say what is "right" or "wrong"?

7. Security Consideration 

   since DSTM is used in an intranet environement. In this scenario, If
 
==> s/environement/environment/

Also, since the TEPs are inside an intranet, they can not be
   used as an open relays.

==> without proper policies, they probably can't be.. but that's rather 
courageously put for something that IETF makes no policies for.  Need more 
discussion.

==> Decapsulation of tunneled packets is _always_ potentially dangerous.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords