Hi Magnus,
On 08/10/2012 13:29, Magnus Westerlund wrote:
Hi Stewart,
See inline for comments
On 2012-10-08 05:37, Stewart Bryant wrote:
Stewart Bryant has entered the following ballot position for
draft-ietf-6man-udpchecksums-04: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to
get to yes on this draft also, since I support the liberalization of this
protocol design when used for tunnelling. Specifically point 6 in this
draft is relevant to this discussion.
Acknowledged
Additionally a tunnel may not have any way of knowing if the payload is
protected (as you suggest), since normally a tunnel has no knowledge of
the payload characteristics.
No, but a tunnel know what general class of traffic it encapsulates. Is
it IPv4 that has at least IPv4 header checksums and possibly non-zero
transport checksums, or are they some type of other L2 frames that has
checksums as part of their frame headers. It is this type of knowledge
in the tunnel payload we want the tunnel designer to consider if they
need additional checksums or not.
Sure you know if you are carrying IP or L2, but L2 mostly carries
IP anyway. However you do not actually know what the user
is going to carry over L2, and really have no right to know. You
have to treat it as opaque traffic.
In any case, as I said we take no precautions in PWs and we do
not observe any issues carrying 'L1' or L2 over PW over MPLS
without a c/s at either the network or the tunnel layer.
In point 7 you suggest that an application cannot rely on packet length.
When PWs are used for tunneling we rely on exactly that (except in the
case of packets shorter than 64 octets for Ethenet padding reasons), and
I am not aware of any reported issues. Thus when the application is
tunnel encap/decap there is a body of evidence that suggests that this
OK.
First of all, I would like to understand a bit more about these
experiences from pseudowires. Which type of psuedowires are we talking
about here. And the derived experiences over which type of lower layer
are being used. Is this IPv6/UDP or something else like MPLS?
I am talking about PW/MPLS. Although PW/L2TP/IP exist in theory
there is very little deployment. The most common PWs seem to be
Ethernet (carrying whatever the Ethernet is carrying, IP but other
protocols as well), ATM and TDM. There is also some Frame Relay
(again with c/s removed and reconstructed), in all cases
carried directly over MPLS.
Secondly, it is likely that psuedowires is designed such that an error
in the length field do not result in any corruption of any state or
irregularities in processing that cause any substantial issues beyond
possibly loosing that packet from its intended context.
Yes, PWs are stateless, but the application receiving the packet
has unknown properties and if we make a mistake on the length
the application will get a corrupt packet with a valid datalink c/s.
However I have never heard this type of error discussed.
>From my perspective, trying to say that there is no risk with removing
the UDP checksum even for a limited context is like trying to prove a
negative. I am certain that some environments have very low corruption
rates, but there might be other environments for IPv6 where it is much
higher.
I wished someone would repeat Stone and Patridge's investigation to get
better understanding of the behaviors of IPv4 and IPv6 in this regards
at different points in today's Internet.
My point is that we have a practical experiment ongoing with the
huge number of PWs in deployment running over MPLS without
c/s protection at the tunnel or network layer and I have never seen
anyone raise an issue in either the PWE3 or MPLS WG. Hence
my conclusion that whilst there is a theoretical risk, the evidence
is that there are no reported issues.
Note that I am only discussing the tunnel case, I make no comment
on any other type of application.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
There is some text in the earlier part of document that looks like it
should be written in RFC2119 format. In this case it is not important
because the normative change is later and this used RFC2119 directives,
however the authors should consider making the document self consistent
in this regard.
I guess you are referring to some text in the discussion. There are
similarities in the discussion with the specification text as it is
motivation why things are like they are. But I think the section
differences and in addition the actual normative text is formulated in a
different way that makes it unsuitable to apply RFC 2119 text on that
earlier sections.
OK, I leave this to your judgement.
- Stewart
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
