IP/ICMP Translation Algorithm
draft-ietf-behave-v6v4-xlate-23

Magnus Westerlund has raised a concern.
I have asked the document shepherd to prepare a response to Magnus's concerns, outlining the discussions about zero checksums that have already taken place.

From Magnus:
"I have taken a look at the new text. I am quite concerned about one thing.

Section 4.5:


  3.  Forwarding the packet without a UDP checksum.

      A stateless translator can translate fragmented UDP IPv4 packet
      under this condition.

Unless we modify RFC 2460 (see 6man debate about v6 and zero checksum) we can't allow this option to be used in the direction v4-v6. And it shouldn't occur in the other direction for the same reason that it is an illegal packet.

Thus I think this 3rd option shouldn't be included at this stage as it will create illegal packets.

For the same reason that it violates RFC 2460 I think also the section
5.5 change is inappropriate:

  For UDP, if an IPv6 UDP packet arrives with a 0 checksum, a UDP
  checksum SHOULD NOT be generated for that IPv4 packet.  Otherwise,
  the translator SHOULD recalculate and update the transport-layer
  checksum.  The translator MAY have a configuration option permitting
  it to zero the UDP checksum in some or all traffic.


I have not looked at any discussion leading up to this changes."

[Ballot discuss]
[Updated]

Modulo the issues listed below I have No Objections to the publication of this document:

As per ID nits , section 1 D, any -bis document that obsoletes another document needs to list changes since the previous version. (No need to list every comma, just major changes).

[Ballot discuss]
This document is in very good shape (as is the entire document set
on NAT64) and should move forward. However, before recommending that
this particular document gets final approval, I would like to discuss
on issue. The document explains:

  Also, when the IPv4 sender does not set the DF bit
  the translator MUST always include an IPv6 fragment header to
  indicate that the sender allows fragmentation.
  ...
  In addition, the rules in section 3.1 use
  the presence of an IPv6 fragment header to indicate that the sender
  might not be using path MTU discovery (i.e., the packet should not
  have the DF flag set should it later be translated back to IPv4).
  ....
  If the DF bit is set and the packet is not a fragment (i.e., the MF
  flag is not set and the Fragment Offset is equal to zero) then the
  translator SHOULD NOT add a Fragment header to the resulting packet.
  ...
  If there is a need to add a Fragment header (the DF bit is not set or
  the packet is a fragment) the header fields are set as above with the
  following exceptions:

In other words, DF=0 implies a fragment header in IPv6. This has been
shown to cause operational difficulties in practice, as even traffic
that in no way needed fragmentation will have a fragmentation header,
which may result in difficulties due to limited firewall fragmentation
support in IPv6, and so on.

Perhaps the spec is right in recommending this, but I would like to
understand exactly why it says what it says, and what the downside
of a more relaxed recommendation might be. (FWIW, I'm sending this
message behind a NAT64 device that uses a relaxed recommendation.)

[Ballot discuss]
When a translator receives an unfragmented UDP IPv4 packet and the
checksum field is zero, the translator SHOULD compute the missing UDP
checksum as part of translating the packet. 

There needs to be text explaining how the translator know whether or not to add the missing checksum. I understand that this is now a more complex decision than it used to be as a result of proposals to relax the requirement to include a UDP checksum for IPv6 depending on the application requirement.

My reading of this specification is that in the reverse direction (IPv6 to IPv4), when a non checksum neutral address is used a check sum will be added to the UDP header carried by the IPv4 packet, and yet I see no discussion of whether this can be turned off, or of the implications for the IPv4 host (which conceivably may not be able to operate with UDP checksum)

[Ballot discuss]
Tero Kvinen's security directorate review indicated that the security considerations are incomplete with respect to the impact of IPsec's AH and ESP on translation.  I have not seen a response to this message (and there have been no
updates to the document), and personally believe these issues should be addressed.  That is, I consider these issues
blocking.  Please work with Tero to scrub the text!

The full message is available at:
                  http://www.ietf.org/mail-archive/web/secdir/current/msg01762.html

[Ballot comment]
3.  Translating from IPv4 to IPv6

  Path MTU discovery is mandatory in IPv6 but it is optional in IPv4.
  IPv6 routers never fragment a packet - only the sender can do
  fragmentation.

[...]

  However, when the IPv4 sender does not set the Don't Fragment (DF)
  bit, the translator MUST ensure that the packet does not exceed the
  path MTU on the IPv6 side.  This is done by fragmenting the IPv4
  packet so that it fits in 1280-byte IPv6 packets, since that is the
  minimum IPv6 MTU.  Also, when the IPv4 sender does not set the DF bit
  the translator MUST always include an IPv6 fragment header to
  indicate that the sender allows fragmentation.

Are these 2 paragraphs in conflict?

[Ballot discuss]
[Updated]

Modulo the issues listed below I have No Objections to the publication of this document:

As per ID nits , section 1 D, any -bis document that obsoletes another document needs to list changes since the previous version. (No need to list every comma, just major changes).

ID-nits tool report for this document:

Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

[...]

  ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460)

Is use of RFC 1883 intentional?

[...]

  -- Obsolete informational reference (is this intentional?): RFC 2766
    (Obsoleted by RFC 4966)

What is the relationship between this document and RFC 4966?

[Ballot discuss]
I haven't reviewed the document yet, but after a quick scan of the document I don't see a section list changes since RFC 2765.

(1.a) Who is the Document Shepherd for this document?

draft-ietf-behave-v6v4-xlate-11
Dave Thaler, dthaler@microsoft.com

Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Yes.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has received significant WG review.
No concerns.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

No concerns.

Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

None.

(1.e) How solid is the WG consensus behind this document?

Solid.

Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The WG has a good understanding of, and agreement with, this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No such threats or appeals.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
and http://tools.ietf.org/tools/idnits/).

Yes.

Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The document does not specify a MIB, media type, or URI, and thus
does not need to meet those review criteria.

If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Intended Status: Standards Track

(1.h) Has the document split its references into normative and
informative?

Yes

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All normative references are to RFCs, either standards track or BCP.

The document shepherd observed that idnits complains about the license:

== You're using the IETF Trust Provisions' Section 6.b License Notice from 12
Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
http://trustee.ietf.org/license-info/)

however, the authors are using xml2rfc which does not support this
new license text.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

There are no registries.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains no such formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document forms a replacement of the Stateless IP/ICMP
Translation Algorithm (SIIT) described in RFC 2765. The algorithm
translates between IPv4 and IPv6 packet headers (including ICMP
headers).

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

The primary issues raised dealt with fragment handling.
An investigation was done to determine how much of a problem not
getting ICMPv6 "packet too big" messages is on the public Internet,
and it was found to be a bigger problem than originally anticipated.
As such, this changed the WG opinion from rough consensus on
one approach to a strong consensus on a different appoach on
the final document.

Document Quality
Are there existing implementations of the protocol?

Yes,
http://www.ietf.org/mail-archive/web/behave/current/msg08102.html

Have a
significant number of vendors indicated their plan to
implement the specification?

Yes, several vendors are actively implementing the specification.

Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

They are listed in the document's acknowledgement section.

If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

No such reviews were necessary.

Personnel
Who is the Document Shepherd for this document?

Dave Thaler, dthaler@microsoft.com

Who is the
Responsible Area Director?

Magnus Westerlund, magnus.westerlund@ericsson.com

If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

The document doesn't require IANA experts.