[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dccp] Re: DCCP and draft-ietf-v6ops-v6onbydefault-01.txt

Hi all, responding to a longago mail:

First off, I think that DCCP is more like TCP than UDP.

Second off, I disagree with the draft's approach for TCP. Maybe this discussion has already been had.

The -02 draft suggests, basically, that IPv6 Destination Unreachable is a hard error during connection setup, so that the application can cycle through different addresses. It notes also that "TCP MUST NOT abort connections when receiving ICMP Destination Unreachable messages that indicate "soft errors"," according to RFC 1122. These are in conflict.

But RFC 1122 also says that TCP "SHOULD make the information [about the soft error] available to the application". This shows a way out of the conflict. We can leave IPv6 Dest Unreach a soft error, like IPv4 Dest Unreach, while still supporting address cycling. Simply specify that TCPv6 stacks SHOULD provide an API by which the application can request that soft errors end the connection right away (one form of 'making the information available'). This change is more incremental than the change currently proposed, and less invasive to the stack (no worries about SYN-SENT/SYN-RECEIVED state and so forth).

The text I've suggested for DCCP below takes this approach.

Also, an editing comment: the draft seems quite verbose.

Thanks for your solicitation,
Eddie



2.3.4 DCCP Implications

DCCP implementations should let applications request that "soft errors", including ICMP Destination Unreachable errors, be reported immediately. Applications that can try multiple addresses to reach a given host SHOULD use this API to reduce potential transport-associated delay during connection setup. Applications should generally turn off this API once a connection has been successfully initiated.



On Apr 23, 2004, at 1:14 PM, Aaron Falk wrote:

I didn't see a response to this note. Would someone like to draft some text and circulate it by the list?

THanks,

--aaron


On Mar 31, 2004, at 8:39 PM, Pekka Savola wrote:

Hi,

draft-ietf-v6ops-v6onbydefault-01.txt has brought up some issues wrt.
handling of ICMP messages in transport protocols, in section 2.3.  The
document is in v6ops WG last call for Informational at the moment.

I believe the situation with DCCP is quite similar to UDP:

--------------
2.3 Transport Protocol Robustness

Making the same set of assumptions as Section 2.2, regardless of how
long the network layer takes to determine that the IPv6 destination
is unreachable, the delay associated with a connection attempt to an
unreachable destination can be compounded by the transport layer.
When the unreachability of a destination is obviated by the reception
of an ICMPv6 destination unreachable message, the transport layer
should make it possible for the application to deal with this by
failing the connection attempt, passing ICMPv6 errors up to the
application, etc... Such messages would be received in the cases
mentioned in Section 2 in which a node has no default routers and NUD
fails for destinations assumed to be on-link, and when firewalls or
other systems that enforce scope boundaries send such ICMPv6 errors
as described in Section 3.1 and Section 3.3.
[...]

2.3.2 UDP Implications

As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass
to the application layer all ICMP error messages that it receives
from the IP layer. As a result, proper handling destination
unreachability by UDP applications is the responsibility of the
applications themselves.
-------------

1) is this being handled differently in DCCP?

2) would you like to propose text to describe the situation with DCCP?

On behalf of v6ops WG,
 Pekka

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings