Subject: (ngtrans) Re: Last Call: Stateless IP/ICMP Translator (SIIT) to Proposed Standard

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Aug 1999 09:15:45 -0500

C. M. Heard/VVNET, Inc. wrote:
> 
> Here are some comments on the Stateless IP/ICMP Translator (SIIT) document
> <draft-ietf-ngtrans-siit-06.txt>, for which the above-referenced last call
> was issued on Thursday, 05 Aug 1999.
> 
> 1.) Section 4.1., "Translating IPv4 Headers", near line 592:
> 
>            Traffic Class:
>                    Copied from IP Type Of Service and Precedence field
>                    (all 8 bits are copied).  According to [DIFFSERV] the
>                    semantics of the bits are identical in IPv4 and IPv6.
>                    However, in some IPv4 environments these fileds might
>                                                             ^^^^^^
>                                                             fields
>                    be used with the old semantics of "Type Of Service
>                                     ^^^
>                                   RFC 791
>                    and Precedence".  An implementation of a translator
>                    SHOULD provide a the ability to ignore the IPv4 "TOS"
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                    and always set the IPv6 traffic class to zero.
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Comment:    The marked text in the last sentence  should say "SHOULD
>             provide the ability to zero out bits 3-7 of the IPv4 TOS
>             byte and copy only bits 0-2 (the IPv4 Precedence bits)
>             into the IPv6 traffic class byte."
> 
> Rationale:  According to Section 4 of RFC 2474 [DIFFSERV], DS field
>             (TOS byte) values of 'xxx000|xx' are reserved as a set
>             of class selector (aka precedence) codepoints.  These are
>             required to map to class selector PHBs whose semantics
>             are compatible with RFC 791 Precedence field usage.
>             SIITs can and should take advantage of this Diffserve
>             backward-compatibility feature.
> 

Absolutely not. The current wording is fine. What gets copied or 
does not get copied is a very complex question that is currently
an open issue in the diffserv WG. The SIIT document should
not attempt to specify this at all, apart from a sensible
default behaviour which is what the current text does.

...

> 3.) Section 5.1., "Translating IPv6 Headers", near line 964:
> 
>            Type of Service and Precedence:
>                    Copied from the IPv6 Traffic Class (all 8 bits).
>                    According to [DIFFSERV] the semantics of the bits are
>                    identical in IPv4 and IPv6.
> 
> Comment:    The following text (or its equivalent) should be added:
> 
>                    However, in some IPv4 environments these bits might
>                    be used with the RFC 791 semantics of "Type Of Service
>                    and Precedence".  In order to accomodate such networks
>                    an implementation of a translator SHOULD provide the
>                    ability to zero out the IPv4 TOS byte unless the
>                    Traffic Class byte contains one of the Class Selector
>                    codepoints (as defined in section 4 of [DIFFSERV]), in
>                    which case it should copy bits 0-2 into IPv4 TOS byte
>                    and zero out bits 3-7.
> 
> Rationale:  See comment #1 above.  Note that the two LSBs of the Traffic
>             Class octet are not defined by [DIFFSERV], but should not be
>             copied because RFC 791 specifies that their values are zero.

Disagree, see above. The current text is OK until we have a full spec 
from  diffserv. Since the LSBs are being used for ECN, copying them 
seems reasonable at this time.

   Brian Carpenter
   diffserv co-chair

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Tue, 10 Aug 1999 22:59:33 -0700 (PDT)

Traffic Class:

2.) Section 4.1., "Translating IPv4 Headers", near line 640:

   If IPv4 options are present in the IPv4 packet, they are ignored
   i.e., there is no attempt to translate them.

Comment:    This will do the wrong thing if there is an unexpired
            IPv4 source route option.  It will cause the packet to
            be forwarded to the IPv6 translation of the destination
            address in the IPv4 header, which is an intermediate hop,
            and would leave no indication in the translated packet of
            what the ultimate destination was supposed to be.  Instead,
            if an unexpired IPv4 source route option is present, the
            translator should send an ICMPv4 error message with type=3
            (destination unreachable) and code=5 (source route failed)
            back to the sender.

Possible replacement text:

   If options other than an expired source route option are present
   in the IPv4 packet, they are ignored, i.e., there is no attempt to
   translate them.  If an unexpired source route option is present
   then the packet MUST NOT be translated, and an ICMPv4 "destination
   unreachable/source route failed" (Type 3/Code 5) error message
   SHOULD be returned to the sender.

Note:       I am assuming that the words "destination address" in the
            second sentence of Section 4.5, "Knowing when to Translate",
            refer to the destination address in the IPv4 header, not
            to the ultimate destination address in an unexpired source
            route option.  If that is not the case then Section 4.5
            needs to be clarified.

4.) Section 5.1., "Translating IPv6 Headers", near line 999:

           Source Address:
                   If the IPv6 source address is an IPv4-translated or
                   an IPv4-mapped address then the low-order 32 bits of
                   the IPv6 source address is copied to the IPv4 source
                   address.  Otherwise, the source address is set to
                   127.0.0.1.  The use of 127.0.0.1 is to avoid
                   completely dropping e.g. ICMPv6 error messages sent
                   by IPv6-only routers.

Comment:   According to Section 3.2.1.3 RFC 1122 (the host requirements
           document), any address of the form 127.x.x.x is an internal
           loopback address which "MUST NOT appear outside a host".
           The section goes on to say that "[a] host MUST silently discard
           an incoming datagram containing an IP source address that is
           invalid by the rules of this section" (and my IPv4 implementation
           goes out of its way to do just that).  Similarly, RFC 1812
           (the router requirements document) states thet "[a] router
           SHOULD NOT forward, except over a loopback interface, any
           packet that has a source address on network 127."

           A much better choice would be 0.0.0.0, which is recognized by
           both documents as a legal source address.

5.) Section 5.1., "Translating IPv6 Headers", near line 1022:

   If any of an IPv6 hop-by-hop options header, destination options
   header, or routing header are present in the IPv6 packet, they are
   ignored i.e., there is no attempt to translate them.  However, the
   Total Length field and the Protocol field would have to be adjusted
   to "skip" these extension headers.

Comment:    This will do the wrong thing if there is a type 0 routing
            header with a non-zero Segments Left field.  It will cause
            the packet to be the IPv4 translation of the destination
            address in the IPv6 header, which is an intermediate hop,
            and would leave no indication in the translated packet what
            the ultimate destination was supposed to be.  Instead, if a
            routing header with a non-zero Segments Left field exists
            in a packet that is presented for translation, the translator
            should send an ICMPv6 error message with type=1 (destination
            unreachable) and code=2 (not a neighbor) back to the sender.

Possible replacement text:

   If any of an IPv6 hop-by-hop options header, destination options
   header, or routing header with the Segments Left field equal to
   zero are present in the IPv6 packet, they are ignored i.e., there
   is no attempt to translate them, and the Total Length field and
   the Protocol field are adjusted to "skip" these extension headers.
   If a routing header with a non-zero Segments Left field is present
   then the packet MUST NOT be translated, and an ICMPv6 "destination
   unreachable/not a neighbor" (Type 1/Code 2) error message SHOULD
   be returned to the sender.

Note:       I am assuming that the words "IPv4-mapped destination
            address" in Section 5.4, "Knowing when to Translate",
            refer to the destination address in the IPv6 header,
            not to the ultimate destination address in an unexpired
            routing header (one with the Segments Left field not
            equal to zero).  If that was not the intent, then Section
            5.4 needs to be clarified.

6.) Section 1.1., "Applicability and Limitations",near line 259:

   [ ... ]   It could be possible to define a translation between source
   routing in IPv4 and IPv6.  However such a translation would not be
   semantically correct since the IPv4 source routing option performs a
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   "record route" function as the nodes listed in the source route are
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   traversed and the IPv6 routing header does not include the record
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   route aspect.  [ ... ]
   ^^^^^^^^^^^^

Comment:    The marked text is misleading, and should be removed.

Rationale:  Any such translation would indeed be semantically incorrect,
            although not for the reason given.  The correct reasons are
            (a) that the IPv4 SSRR option has no IPv6 equivalent and
            (b) that the recorded route in an expired IPv4 LSRR option
            contains the addresses of the intermediate hop interfaces on
            which the datagram was _sent_ (RFC 1812, Section 4.2.2.2),
            whereas the list of addresses in an IPv6 type 0 routing header
            with the Segments Left field equal to zero contains the
            addresses of the intermediate hop interfaces to which the
            datagram was _addressed_ (RFC 2460, Section 4.4).  It does
            not seem worthwhile to belabor these points, however, so I
            have suggested that the marked text just be removed.

7.) Section 1.1., "Applicability and Limitations",near line 238:

   The IPv6 protocol [IPv6] has been designed so that the transport
   pseudo-header checksums are not affected by such a translation thus
   the translator does not need to modify normal TCP and UDP headers.
   The only exception being unfragmented IPv4 UDP packets which need to
            ^^^^^^^^^^^^^^^
            exceptions are
   have a UDP checksum computed since a pseudo-header checksum is
   required for UDP in IPv6.  Also, ICMPv6 include a pseudo-header
   checksum but it is not present in ICMPv4 thus the checksum in ICMP
   messages need to be modified by the translator.  In addition, ICMP
   error messages contain an IP header as part of the payload thus the
   translator need to rewrite those parts of the packets to make the
   receiver be able to understand the included IP header.  However, all
   of the translators operations, including path MTU discovery, are
          ^^^^^^^^^^^
          translator's
   stateless in the sense that the translator operates independently on
   each packet and does not retain any state from one packet to another.
   This allows redundant translator boxes without any coordination and a
   given TCP connection can have the two directions of packets go
   through different translator boxes.

Cordially,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Wed, 11 Aug 1999 13:32:55 -0700 (PDT)

Regarding my comments on translating IPv4 DS field/TOS byte to

> seems reasonable at this time.

My comments were specifically directed at the translations in the case
where the IPv4 network is an RFC 791-only network.  Even if I am incorrect
in thinking that it is desirable to preserve the Precedence/Selector Class
encodings in that case, there seems to be an inconsistency in the text as
it stands.

The current text in Section 4.1 recommends that a translator have the
capability to zero out the IPv6 Traffic Class octet, rather than copying
it from the TOS octet when the latter is coming from an RFC 791-only
network.  That at least prevents a non-diffserve encoding from being
copied into the Traffic Class octet.

The current text in Section 5.4, however, does not have any analogous
provision for preventing a diffserve-encoded Traffic Class octet from
being copied into the TOS octet at the boundary of an RFC 791-only
network.

It seems inconsistent to recommend the "zero out" capability in one
direction of translation and not the other.

Would it be reasonable to suggest that Section 5.1 should recommend that
a translator have the capability to zero out the IPv4 TOS octet rather
than copying it from the IPv6 Traffic Class octet, when the packet is
being sent to an RFC 791-only network?

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Aug 1999 17:14:42 -0500

Mike,

We've only had a quick look at this so far in diffserv but the
main conclusion is that there is no simple answer. I can come
up with plausible scenarios for practically any default mechanism.
In fact it is just as complex as the issues that arise at any
diffserv/diffserv border or any diffserv/RFC 791 border; the fact
that there happens to be an IPv4/IPv6 translation is almost
beside the point. I'm quite sure that whatever goes into SIIT
now, it will be obsoleted or re-visited when we have worked
this through in diffserv. I did look at the SIIT draft some
time ago and concluded that the current wording is as harmless
as we can get. But I have no problem with your suggested change

> being sent to an RFC 791-only network?

The alternative would be to hold up SIIT until diffserv has
reached a conclusion on this issue, but I think that would be
unreasonable.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Wed, 11 Aug 1999 22:08:15 -0700 (PDT)

Brian E Carpenter wrote:
> We've only had a quick look at this so far in diffserv but
> the main conclusion is that there is no simple answer. 
> [ ... ]  I'm quite sure that whatever goes into SIIT

In light of what Brian has said, I wish to revise my last call comments #1
and #3 to read as follows:

           Traffic Class:

...

                   However, in some IPv4 environments these bits might
                   be used with the old semantics of "Type Of Service
                   and Precedence".  An implementation of a translator
                   SHOULD provide the ability to ignore the IPv6 traffic
                   class and always set the IPv4 "TOS" to zero.

Rationale:  To provide consistent behaviour in both directions of translation.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Aug 1999 20:13:26 -0700 (PDT)

Mike,
Thanks for your comments.

I'm working on addressing your comments on TOS and source routing
in a new version of the draft (using mostly your suggested text).

However, I'm not clear what to do with
the 127.0.0.1 comment. I'm interesting in input from the ngtrans WG since I
think we have two options:
1. Silently drop an IPv6 packet which doesn't have an IPv4-translated or
   an IPv4-mapped source address.
2. Make the source address be 0.0.0.0 in this case.
   RFC 1122 states:
                 This host on this network.  MUST NOT be sent, except as
                 a source address as part of an initialization procedure
                 by which the host learns its own IP address.

>            both documents as a legal source address.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 18 Aug 1999 20:28:14 -0700 (PDT)

>    be returned to the sender.

"not a neighbor" was removed from ICMPv6 a while back and code 2 has been
recycled to mean "beyond scope of source address".

How about this instead:
If a routing header with a non-zero Segments Left field is present
then the packet MUST NOT be translated, and an ICMPv6 "parameter problem/
erroneous header field encountered" (Type 4/Code 0) error message, with
the Pointer field indicating the first byte of the Segments Left field, SHOULD
be returned to the sender.

The alternative would be to use "unreachable/no route to destination"
which seems a lot less descriptive.

   Erik

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Wed, 18 Aug 1999 21:42:24 -0700 (PDT)

> recycled to mean "beyond scope of source address".

In that case, there are a couple of places in the draft where that need to
be fixed:

Section 4.2, "Translating UDP over IPv4", near line 795:

              Code 5: Set Code to 2 (not a neighbor).

and 5.2, "Translating ICMPv6", near line 1104:
   
              Code 2: Set Code to 5 (source route failed).

> which seems a lot less descriptive.

Either one sounds fine to me.

Mike

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 19 Aug 1999 10:22:49 -0700 (PDT)

> In that case, there are a couple of places in the draft where that need to

Yes, thanks for catching those.

  Erik