Subject: Re: (ngtrans) comments on SIIT 04

From: "George Tsirtsis" <[email-masked]>
Date: Wed, 17 Mar 1999 09:11:56 PST

>> Here are our (Kazu and Sumikawa) comments on SIIT 04:
>> 
>> (1) Is IPv4-translated address routable in an IPv6 site?
>
>The draft (currently) says that this is out of scope.
>
>If we want a complete solution we need to specify ipv6-in-ipv6
>tunneling plus the mechanisms to avoid any configuration of tunnels.
>This isn't that hard and I think the same mechanism can be used
>for AIIH (with the difference that AIIH would need ipv4-in-ipv6
>tunneling). But when I wrote the draft I just wanted to get the 
>header translator component written down.
>

I do not think that you should talk about this things in the SIIT draft. 
On the contrary, and as I have said before (and during the ngtrans 
meeting yesterday), I think that SIIT should be "cleaned up" from 
anything that is not Protocol Translation. A lot of the confusion comes 
from the fact that the introductory sections of SIIT give the wrong 
impression that you can buy an SIIT box, put it in the network and it 
will work. In fact as you (Erik) have said, SIIT is NOT a complete 
solution and in order to make it one, you need one of NAT-PT, BIS, IPv6 
in IPv6 tunnel etc.

Some more specific comments:

"Abstract

   This document specifies a transition mechanism in addition to those
   already specified in RFC 1933.  The new mechanism can be used as part
   of a solution that allows IPv6 hosts that do not have a permanently
   assigned IPv4 address to communication with IPv4-only hosts."

The above abstract gives the impression that SIIT could be used in 
combination with dual-stack hosts. I think it should explicitly say that 
Only packets from/to IPv6 ONLY host may be translated.

"1.  INTRODUCTION AND MOTIVATION
...
   There are several different scenarios where there might be IPv6-only
   hosts that need to communicate with IPv4-only hosts.  These IPv6
   hosts might be IPv4-capable, i.e. include an IPv4 implementation but
   not be assigned an IPv4 address, or they might not even include an
   IPv4 implementation.

    - A completely new network ...

    - An existing network where a large number of IPv6 devices are
      added..."

Up to this point you describe applicability and I think it is OK but 
then you continue describing possible solutions that are out of scope of 
SIIT.

I think the rest of section 1 should be removed or greatly condensed. 
This is because what you describe are incomplete ideas that can make 
SIIT a complete solution. These ideas, however, are described in 
separate documents like NATPT and maybe a draft that you (or someone 
else should write) about the solution involving IPv6 in IPv6 tunnelling.

Later you say:

"3.  OVERVIEW

   The protocol translators are assumed ...

   For outbound packets i.e., packets that need to be translated from
   IPv6 to IPv4, it is sufficient to have a route for the IPv4-mapped
   address prefix (::ffff:0:0/96) injected in the internal IPv6 ...

   Inbound IPv4 packets needing translation are likely to have some
   temporary IPv4 address that is drawn from a pool of such addresses.
   Thus the internal IPv4 routing tables could have one or more routes
   for the whole pool that direct the packets to the translator."

The whole of this section is dealing with something that is out of scope 
for SIIT. How the translated packet reaches SIIT depends on the complete 
solution and should be described in separate document see NATPT, BIS and 
the IPv6 in IPv6 solution.

"3.1.  Assumptions

   The IPv6 nodes using the translator must have an IPv4-translated IPv6 
address while it is communicating with IPv4 nodes."

Again this should not be here. "IPv4-translated IPv6" addresses should 
be described somewhere else. Address assignment is dealt with in drafts 
like NATPT, BIS and maybe you should write another draft about 
IPv4-translated addresses...

After Section 4 SIIT becomes what is supposed to be ==> A Protocol 
Translator! 

I hope you see the point of my comments and the fact that unless we 
clearly specify what each document is and what the relation between the 
documents is, confusion will continue...

Thanks
George

*
This is George not having access to his proper e-mail 
*
George Tsirtsis
Internet Transport Research 
BTLABS
Proper e-mail: [email-masked]                      
*
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor
commercial direction of British Telecommunications plc.

Get Your Private, Free Email at http://www.hotmail.com