Subject: [v6ops] new draft: draft-elkins-v6ops-ipv6-end-to-end-rt-needed

From: <[email-masked]>
Date: Fri, 31 May 2013 05:45:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. Please take a look at it and comment.

---

From: Dan Wing <[email-masked]>
Date: Fri, 31 May 2013 17:48:08 -0700

> A new draft has been posted, at http://tools.ietf.org/html/draft-elkins-v6ops-ipv6-end-to-end-rt-needed. Please take a look at it and comment.

I read that document and draft-elkins-v6ops-ipv6-packet-sequence-needed.  Both the documents talk about how IPID is useful on IPv4 (if the sender is monotonically increasing the IPID, which is a necessity for the existing system to operate) and how routers sometimes send a packet twice (which is normal behavior of Ethernet) and that the monotonically increasing IPID helps distinguish Ethernet re-transmissions from host stack retransmissions.

I note that Real Time Protocol (RTP, RFC3550; previously RFC1889 published in 1996) had similar needs and solved them at the RTP application layer with sequence numbers and timestamps, and with its RTCP feedback channel.  The two I-Ds that I reviewed did not discuss why this application timing problem cannot be solved at the application layer like RTP solved it.

I did not see an analysis of forcing an IPv6 fragmentation header (as done by 4rd for transparency, http://tools.ietf.org/html/draft-ietf-softwire-4rd), as that could provide a function nearly identical to the existing (ab)use of IPv4 IPID.

-d