Magnus and I updated the draft below to align this revision to the work
on the related RFC 2460 update.
Note of apology - I submitted an interim (rev-09) over the weekend with
an unintended merging of bullets 5,6,7 in section 5. This revision -10
corrects this, by reapplying my edits to rev
of checksums by application designers.
- Possibly best placed in the introduction, indicating that this
document adds to this for the case of tunneling applications.
--
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered
Marshall, and others,
I've now read the new draft:
http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-01
This looks much more like what I expected, thanks.
I've got some concerns with the following para in Section 5:
Whenever originating a UDP packet, an IPv6 node SHOULD compute a
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
Carpenter wrote:
Gorry,
On 2009-11-11 02:42, Gorry Fairhurst wrote:
Brian,
I agree the draft should be updated on this point (and will reference
RFC 3997).
I have two comments/questions:
1) The draft speaks about tunnel encapsulations, and therefore, the
intention (as I recall - others please do
Brian,
I agree the draft should be updated on this point (and will reference
RFC 3997).
I have two comments/questions:
1) The draft speaks about tunnel encapsulations, and therefore, the
intention (as I recall - others please do chime in) was that a tunnel
ingress performing encapsulating
Using UDP-Lite would be fine. I'm not sure how a transition to UDP with
no checksum would help the transport concerns with mis-delivery, etc.
Gorry
Margaret Wasserman wrote:
I had a thought on the use of zero UDP checksums in IPv6...
What if we allowed the use of zero checksums for UDP as
I'd be very concerned if the IETF consensus was to introduce a change to
the UDP checksum without fully evaluating the implications for the
network and before considering the procedures by which new protocols
could access a zero-checksum mode.
As I understand, the proposal to update RFC 2460
Noel Chiappa wrote:
From: Francis Dupont francis.dup...@fdupont.fr
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers too)
OK, so what are the other options for encapsulating a packet in a IPv6
views here and it would be good to get to the bottom of this.
A few other comments in-line,
Gorry
Gorry Fairhurst wrote:
On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento
Rémi Denis-Courmont wrote:
Hello,
I take the freedom to move this to 6man mailing list...
Thanks, please see below.
On Thu, 02 Jul 2009 19:30:54 +0100, Gorry Fairhurst go...@erg.abdn.ac.uk
wrote:
Have you any comments on:
draft-fairhurst-6man-tsvwg-udptt-01
I am trying to figure-out
OK, so the action I take is that I think there should be some text added
to explain this case. When I get to making the next revision, I'll send
you the text to make sure this is covered.
Thanks,
Gorry
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
Gorry Fairhurst wrote
I've submitted a revision of the I-D below, and would be keen to see
some discussion on this list as to whether this could solve the
perceived problem that some tunnel protocols do not wish to employ the
UDP checksum as specified in RFC 2460.
I would like to present this short draft in
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points
list.
In case anyone is interested in more of the background material, the
draft requiring this change is draft-ietf-mboned-auto-multicast-09.txt.
Since March, there has been no public discussion of this. (I'll note
that in April Gorry Fairhurst submitted an alternative,
draft-fairhurst-6man
-designed
application too.
- Incremental updating of checksums is allowed with UDP-Lite, so
middleboxes can process as per UDP. A middlebox that recalculates or
verifies the checksum would require an IPv6 NAT update to revise the cksum.
Thoughts?
Gorry Fairhurst
Thanks for writing this. It is good to see some arguments recorded, and
I hope we can now proceed to some useful debate and understanding of the
problem and solution. UDP is specified as an Internet Area
specification, and there are network issues (such as IP header
integrity), but the impact
17 matches
Mail list logo
