I agree with the comments from Magnus. I can promise to also check the
next revision for consistency with the udpzero draft, but that would be
easier with the reorganisation, that Magnus has suggested.
I also add the following:
There are some pointers to use-cases in the introduction that are not
referenced, whereas I would have expected quite tightly-defined
use-cases in line with the udpzero draft.
"More recently, a discussion on the DCCP mailing list covered
the UDP over IPv6 checksum issues.
- I recall this in the context of DCCP-over-UDP, but the conclusion was
that UDP MUST provide a checksum. I think if you want to discuss DCCP,
you should also state the conclusion and rationale why (i.e. because of
the need to protect the header fields).
The draft later also says:
"o A key cause of this issue generally is the lack of protocol
support in middleboxes. Specifically, new protocols, such as
DCCP, are being forced to use UDP tunnels just to traverse an end-
to-end path successfully and avoid having their packets dropped by
middleboxes. If this were not the case, the use of UDP-lite might
become more viable for some (but not necessarily all) lightweight
tunneling protocols."
- However, the DCCP working group specifically chose not to use a tunnel
approach, and instead used a double encapsulation, in which the
processing at the receiver uses both the UDP and DCCP header fields,
specifically the UDP checksum was mandated. Maybe this is not the best
example?
I'm not sure whether UDP-Lite will be supported over IPv6 middleboxes,
because I don't personally know about significant deployment of either.
"Other users of UDP as a tunneling
protocol, for example, L2TP..."
- Do you envisage this as a host tunnel?
In section 1.3 the draft describes:
"UDP keep-alive packets with checksum zero can be sent to validate
paths, given that paths between tunnel endpoints can change and so
middleboxes in the path may vary during the life of the
association."
- I agree. Are these being defined for this specification? What
functions are required? And if so, are the keep-alive datagrams of any
specific format, periodicity, and how do they validate the path, i.e.,
are the datagrams acknowledged?
The draft also says:
"We suggest
that decoupling IPv6 header protection from transport generally
should be studied in this workgroup. One approach might be to
consider an extension header for IPv6 containing (at least) a
header checksum. However, that is beyond the scope of this draft."
- I'm not for or against this, but there are considerations and we need
to be clear if this is an IETF recommendation, or a good idea for some
future work: There have been other initiatives in the IETF that have
looked at the pros and cons of separating the endpoint and routing
functions.
I'd be most happy to do a detailed review of a new version.
Gorry
On 14/04/2011 13:09, Chimento, Philip F. wrote:
Hi Magnus:
Very good comments, thank you. We'll make the changes and address these.
Marshall: Do you have the latest XML? If you send it to me, I can try to get
these comments addressed by early next week (Mon or Tue).
Thanks.
Regards, Phil
On 4/14/11 8:01 AM, "Magnus Westerlund"<magnus.westerl...@ericsson.com>
wrote:
(resend due to bad author alias address)
Hi,
I have made a review of the draft and have some comments on it.
1. Needs to indicate that it updates RFC2460 (when approved). This
usually goes into the header of the front page. The abstract and as part
of the introduction.
2. The abstract is way to meager. It needs to make clear, what it does,
that there are limitations and that it updates RFC 2460.
3. Style of writing. This is a document that updates and will be the
specification of a change of the IPv6 specification. Currently it still
reads like a change proposal. From my perspective it needs to be more
authoritative. This is something we have decided to do. Thus the
document should be written like:
1. Introduction: We are changing the UDP zero checksum rule in IPv6.
2. Short motivation why.
3. Change to specification. Old text that is replaced. New text.
Some places where this is evident:
- Section 1, last paragraph on page 3: Not long term relevant and using
terms that make less sense in an RFC.
- Section 1.4 "Recommend Solution": Wrong title. Should be its own main
section. First paragraph.
4. Section 1.4:
In cases, where the encapsulating
protocol uses a zero checksum for UDP, the receiver of packets in
the allowed port range MUST NOT discard packets with a UDP
checksum of zero.
"in the allowed port range" seems wrong, isn't "to a port that has been
enabled to receive zero checksum" so that the full sentence reads:
In cases, where the encapsulating protocol uses a zero checksum for UDP,
the receiver of packets to a port that has been enabled to receive zero
checksum MUST NOT discard packets with a UDP checksum of zero.
5. Section 1.4 bullet 1:
1. IPv6 protocol stack implementations SHOULD NOT by default
allow the new method. The default node receiver behaviour
MUST discard all IPv6 packets carrying UDP packets with a zero
checksum.
I think "new method" is unclear in this sentence. Yes, I know it is from
my draft. However, in the context of actually doing the change it needs
to be more crisp and clear.
6. Section 1.4, bullet 3:
3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams
with a zero-checksum. This should remain the case for any
datagram received on a port that does not explicitly enable
zero-checksum processing. A port for which zero-checksum has
been enabled MUST NOT log the datagram.
Should we clarify that it MUST NOT log for the reason of it having a
zero checksum. It may still be logged but for other reasons. The
simplest change appears to say:
A port for which zero-checksum has been enabled MUST NOT log the
datagram for that reason.
7. Section 1.4, bullet 5:
5. UDP Tunnels that encapsulate IP MUST rely on the inner packet
integrity checks provided that the tunnel will not
significantly increase the rate of corruption of the inner IP
packet. If a significantly increased corruption rate can
occur, then the tunnel MUST provide an additional integrity
verification mechanism. An integrity mechanism is always
recommended at the tunnel layer to ensure that corruption
rates of the inner most packet are not increased.
I think the first "MUST" is actually not correct. I think "MAY" is
actually more correct. If you transport IP as inner packet, then you MAY
rely on that being corruption verified by itself, the outer header
doesn't need to take that responsibility providing that the corruption
rate will not be increase. However disallowing additional checks was not
the intention here.
8. Section 1.5 should have its own main section.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com
----------------------------------------------------------------------
Regards,
Phil Chimento
JHU/APL
240-228-1743
443-778-1743
philip.chime...@jhuapl.edu
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
