transmech editorial comments

[Pekka Savola <pekkas@netcore.fi>]

Hi, 

when writing up the comments, I thought I remembered to take all the 
substantial ones.. now I see that there a few with a minor point as well, 
but I really don't see resistance to them..

semi-editorial
--------------

  -    The exit node of the tunnel (the decapsulator) receives the
        encapsulated packet, reassembles the packet if needed, removes
        the IPv4 header, updates the IPv6 header, and processes the
        received IPv6 packet.

==> why would the exit node update the IPv6 header?  I assume that would be
done for Hop Limit processing, but that's already covered by the further
processing

   -    The encapsulator MAY need to maintain soft state information for
        each tunnel recording such parameters as the MTU of the tunnel
        in order to process IPv6 packets forwarded into the tunnel.  In
        cases where the number of tunnels that any one host or router is
        using is large, it is helpful to observe that this state
        information can be cached and discarded when not in use.
  
==> s/MAY/may/ (this kind of stuff should be a duplicate of 3.2.2)
==> move the sentence "In cases..." in section 3.2.2, e.g., before the last
paragraph.  (Actually you could consider moving about all of that to sect 
3.2.2 as the state kept in the fixed MTU option is rather small.)

  1)   It would result in more fragmentation than needed.  IPv4 layer
        fragmentation SHOULD be avoided due to the performance problems

==> s/SHOULD/should/ (this really isn't an interop requirement, and the
actual uppercase reqs are later in the spec)

...

3.3.  Hop Limit

   IPv6-over-IPv4 tunnels are modeled as "single-hop".  That is, the
   IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the
   tunnel.  The single-hop model serves to hide the existence of a
   tunnel.  The tunnel is opaque to users of the network, and is not
   detectable by network diagnostic tools such as traceroute.

   The single-hop model is implemented by having the encapsulators and
   decapsulators process the IPv6 hop limit field as they would if they
   were forwarding a packet on to any other datalink.  That is, they
   decrement the hop limit by 1 when forwarding an IPv6 packet.  (The
   originating node and final destination do not decrement the hop
   limit.)

==> this seems a bit unclear forwarding for the case where the tunnel is not
used for forwarding when the hop limit is not decremented.  I tried to think
of a better rewording, but perhaps the easiest fix would be to remove:

That is, the
   IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the
   tunnel.

.. because the description is already there in the next paragraph, and this
one is wrong.


        Header Checksum:

                Calculate the checksum of the IPv4 header.

==> the ID-nits requires to describe how one treats the checksum 
field for the purposes of checksumming.  Maybe a reference IP doc
is OK, nothing more than that.


fully editorial
---------------

   -    Dual IP layer (also known as Dual Stack):  A technique for
        providing complete support for both Internet protocols -- IPv4
        and IPv6 -- in hosts and routers.

   -    Configured tunneling of IPv6 over IPv4:  Point-to-point tunnels
        made by encapsulating IPv6 packets within IPv4 headers to carry
        them over IPv4 routing infrastructures.

==> maybe the latter should be reworded to be similar, like:

"A technique for establishing point-to-point tunnels by ...." ?

2.1.  Address Configuration

   Because they support both protocols, IPv6/IPv4 nodes may be

==> s/they/the nodes/

2.3.  Advertising Addresses in the DNS

   There are some constraint placed on the use of the DNS during
 
==> s/constraint/constraints/

   If an IPv6 node is isolated from an IPv6 perspective (e.g., it is not
   connected to the 6bone to take a concrete example) constraint #3
   would mean that it should not have an address in the DNS.

==> reword 6bone (someone already mentioned this I think)

   This works great when other dual stack nodes try to contact the
   isolated dual stack node.  There is no IPv6 address in the DNS thus

==> s/This works great/Following these guidelines enhances the the
robustness/ ?

  terminate the TCP connection.  This means that the normal TCP timeout
   of a few minutes apply.  Once TCP times out the application will

==> s/apply/applies/


   -    Determine when to fragment and when to report an ICMP "packet
        too big" error back to the source.

==> s/ICMP/ICMPv6/ or IPv6 ICMP

   as a link layer with a very large MTU (65535-20 bytes to be exact; 20
   bytes "extra" are needed for the encapsulating IPv4 header).  The
   encapsulator would need only to report IPv6 ICMP "packet too big"

==> s/need only/only need/

   such a scheme would be inefficient for two reasons and therefor MUST

==> s/therefor/therefore/

        reassembled at the tunnel endpoint.  For tunnels that terminate
        at a router, this would require additional memory to reassemble

==> s/memory/memory and other resources/

   Hence, the encapsulator MUST NOT treat the tunnel as an interface
   with an MTU of 64 kilobytes, but instead either use the fixed static
   MTU below, or use OPTIONAL dynamic MTU determination based on the
   IPv4 path MTU to the tunnel endpoint.

==> s/below//, s/use//

   having a fixed interface MTU of 1280 bytes.  An implementation MAY
   have a configuration knob which can be used to set a larger value of
   the tunnel MTU than 1280 bytes, but if so the default MUST be 1280
   bytes.  A larger fixed MTU should not be configured unless it has

==> s/than 1280 bytes//, s/if so/if so,/
(because the default must be 1280, no need to repeat)

  large tunnel MTUs to only do so when the MTU of the IPv4 path to the
   tunnel endpoint is large to avoid causing excessive fragmentation.

==> s/large/large enough/

   should not receive any ICMPv4 "packet too big" message as a result of
   the packets it has encapsulated.

==> s/message/messages/

   Encapsulators that have a large number of tunnels can choose between

==> s/can/may/

   Implementations MAY provide a mechanism to allow the administrator to
   configure the IPv4 TTL such as the one specified in the IP Tunnel MIB
   [RFC2667].

==> reword (removes "the one ..."):

   Implementations MAY provide a mechanism, for example IP Tunnel MIB
   [RFC2667], to allow the administrator to configure the IPv4 TTL.

                [RFC3168] for issues relating to the ToS byte and  

==> s/ToS/Type of Service/ (I wonder if we should call the field DSCP...)

        Time to Live:

                Set in implementation-specific manner.

==> reword:

                Set in an implementation-specific manner, as described in
                section 3.3.

...

               41 (Assigned payload type number for IPv6)

==> s/)/)./

        Destination Address:

                IPv4 address of tunnel endpoint.

==>s/tunnel/the tunnel/


   Any IPv6 options are preserved in the packet (after the IPv6 header).

==> this seems like an irrelevant sentence, could be removed?

   The decapsulator MUST be capable of reassembling an IPv4 packet that
   is the maximum of 1280 bytes and the largest interface MTU on the

==> s/interface/(IPv4) interface/

                             All IPv6 options are preserved even if the
   encapsulating IPv4 packet is fragmented.

==> again, this doesn't seem relevant and could be removed.

   The encapsulating IPv4 header is discarded.  The length of the IPv6
   packet MUST be determined from the IPv6 payload length since the IPv4
   packet might be padded (thus have a length which is larger than the
   IPv6 packet plus the added IPv4 header).

==> the relevance of the latter should be clarified, like:

   The encapsulating IPv4 header is discarded.  When reconstructing the 
   IPv6 packet, the length MUST be determined from the IPv6 payload length since the IPv4
   packet might be padded (thus have a length which is larger than the
   IPv6 packet plus the added IPv4 header).

....

   The Interface Identifier [RFC2373] for such an Interface SHOULD be

==> s/2373/3513/ (also later in another place)
==> s/I/i/

   The IPv6 Link-local address [RFC2373] for an IPv4 virtual interface

==> s/L/l/


   +-------+-------+-------+-------+-------+-------+------+------+
   |  FE      80      00      00      00      00      00     00  |
   +-------+-------+-------+-------+-------+-------+------+------+
   |  00      00   |  00   |  00   |   IPv4 Address              |
   +-------+-------+-------+-------+-------+-------+------+------+

==> the bars between the last and second last set of zeros are inconsistent
with the rest...?

 When IP-in-IP
   tunneling (independent of IP versions) is used it is important that
   this not be a tool to bypass any ingress filtering in use for non-
   tunneled packets.

==> s/not be a tool/isn't used/ ?

 Thus the rules in this document are derived based
   on should ingress filtering be used for IPv4 and IPv6, the use of
   tunneling should not provide an easy way to circumvent the filtering.

==> maybe could start a new paragraph from here?

  possibility to circumvent ingress filtering [RFC2827].  This
   specification prevent tunneling from introducing additional

==> s/prevent/prevents/

   weaknesses when IPv4 and/or IPv6 ingress filtering is in used by
   requiring that decapsulators only accept packets if they have been
   
==> s/in//



-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings