IP/ICMP Translation Algorithm
draft-bao-v6ops-rfc6145bis-07

[Ballot comment]
Thanks for addressing the concerns in my DISCUSS.

Boilerplate:
RFC6145 had a pre-5378 boilerplate but this draft does not. I just want to make sure that this was a conscious decision.

[Ballot discuss]
Section 5.1.1:

The following text in the Total Length handling suggests that fragments containing IPsec AH will not get through these translators. Is this intentional? If so, it should be clearly stated. If not, there needs to be an exception defined for AH as well.

"If the Next Header field of the Fragment Header is an extension header (except ESP) then the packet SHOULD be dropped and logged."

Section 5.3:

The following text regarding TTL handling in ICMP messages does not say what to actually do with the TTL value and could lead to ambiguity in implementations.

The ICMP error messages  containing the packet in error MUST be translated just like a normal IP packet (except the TTL value of the inner IPv4/IPv6 packet)

I think the intent (correct me if I am wrong) is to ensure that the the TTL/Hop Limit is not decremented. If so, I would recommend rewording to something like this

The ICMP error messages  containing the packet in error MUST be translated just like a normal IP packet (except that the TTL/Hop Limit value of the inner IPv4/IPv6 packet are not decremented)

[Ballot comment]

Section 1.3:
What are "masking addresses"? Section 6 of RFC4787 provides a good description of hairpinning (maybe worth adding as a reference?) but does not talk about masking addresses.

Boilerplate:
RFC6145 had a pre-5378 boilerplate but this draft does not. I just want to make sure that this was a conscious decision.

[Ballot comment]
Just two questions on this specification.

I'm not understanding why

  The stateless translator SHOULD support explicit address mapping
  algorithm defined in [RFC7757].

  The stateless translator SHOULD support [RFC6791] for handling ICMP/
  ICMPv6 packets.
 
are both SHOULDs. Could you help me understand why they aren't MUSTs?
 
I'm reading this text,

  Total Length:  If the Next Header field of the Fragment Header is not
      an extension header (except ESP) then Total Length MUST be set to
      Payload Length value from IPv6 header, minus length of extension
      headers up to Fragmentation Header, minus 8 for the Fragment
      Header, plus the size of the IPv4 header.  If the Next Header
      field of the Fragment Header is an extension header (except ESP)
      then the packet SHOULD be dropped and logged.
     
and, below that,

  Fragment Offset:  If the Next Header field of the Fragment Header is
      not an extension header (except ESP) then Fragment Offset MUST be
      copied from the Fragment Offset field of the IPv6 Fragment Header.
      If the Next Header field of the Fragment Header is an extension
      header (except ESP) then the packet SHOULD be dropped and logged.
     
and I'm wondering what to do with ESP. I THINK I know, but I'm guessing. Could you consider making this a bit clearer?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-bao-v6ops-rfc6145bis-05.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: joelja@gmail.com, draft-bao-v6ops-rfc6145bis@ietf.org, fred@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IP/ICMP Translation Algorithm (rfc6145bis)) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'IP/ICMP Translation Algorithm (rfc6145bis)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-03-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the Stateless IP/ICMP Translation Algorithm
  (SIIT), which translates between IPv4 and IPv6 packet headers
  (including ICMP headers).  This document obsoletes RFC 6145.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/ballot/


No IPR declarations have been submitted directly on this I-D.