Consider a multi-homed host using a multi-homed transport protocol (such as SCTP) having multiple valid addresses but also having a deprecated address-- from what I understand from this thread, -- we need to allow binding of the deprecated address on the host -- we need to accept connections to the deprecated address I've made these changes in the SCTP stack this is distributed along with KAME.
However, should any new connections (SCTP associations) FROM this host to a peer list the deprecated address as part of the association? Given the existing text and this discussion, it seems that it should not, as other preferred address(es) are available. Of course unless as qualified by the proposed text below-- that it is the only address available (eg. the host is single homed/has a single valid address which happens to be a deprecated address). Comments? --peter [EMAIL PROTECTED] wrote: > > i now understood all the reasoning for accepting TCP SYN to deprecated > address, and corrected netbsd. ok. > > > | "new communication" isn't clear enough, IMHO. > >It would be hard to dispute that given the exchange of the past > >hour or two. > >How would you suggest that it be revised to have the proper effect? > >(That is, to explicitly allow deprecated addresses to be used, other > >than when it is a toss up which address to use). > >Do we currently have a 2462 bis draft? > > here are my proposed changes. > > itojun > > RFC2462 > page 3: > > > in arbitrary communication is unrestricted. Later, an address becomes > > "deprecated" in anticipation that its current interface binding will > > become invalid. While in a deprecated state, the use of an address is > > discouraged, but not strictly forbidden. New communication (e.g., > > the opening of a new TCP connection) should use a preferred address > > when possible. A deprecated address should be used only by > > applications that have been using it and would have difficulty > > switching to another address without a service disruption. > > the last sentence does not meet people's understand. append > ", or there is no other choice than to use deprecated address". > > or, since this is introduction section, we shouldn't go into this > detail here. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
