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

[Pekka Savola <pekkas@netcore.fi>]

Hi,

I also added tcpm WG to Cc: (as you already forwarded this on that 
list later).

As a status update, the TCP part has been put in a separate draft -- 
draft-gont-tcpm-tcp-soft-errors-00.txt.  What is the status wrt. the 
modification you propose in DCCP?

That is, in the IESG evaluation we received feedback that we cannot
publish this document with "solutions" unless the solutions have been
specified in the respective specification (e.g., DCCP drafts, etc.) --
and we'd have to reference them normatively (I think).

More inline on TCP and the genegic approach...

On Wed, 14 Jul 2004, Eddie Kohler wrote:
> 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).

It would indeed be possible to provide an API for the application to
act on the soft error information.  However, I think the application
still cannot ignore the SYN-SENT/SYN-RECEIVED state issues due to
security reasons (otherwise anyone could start aborting the ongoing
connections for those who use the API).

In other words, it would be possible to provide an API (e.g., a socket 
option that could be set) which would abort the connection if it 
receives a soft error in SYN-SENT/RECEIVED states.

Another alternative is to make the change by default, but provide the
identical API (e.g., a socket option) which would prevent the address
cycling -- because one could argue that address cycling is in most
cases a desirable thing to do, and this would be a better "by default"  
behaviour.  Most applications would want to set it in any case, and
doing it by default would achieve a better and easier "application
penetration".

All the approaches have their tradeoffs, of course.  This discussion
needs to be had, possibly in TCPM WG.

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