Subject: RE: need clarification of "deprecated" address

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Aug 2002 08:34:25 -0700

>   | i don't agree with Pekka's take.
> 
> I do agree.   And as I recall, it was the reasoning that was 
> also used, and
> adopted, years ago.

For the record, I agree with Pekka & kre here.

Rich

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Richard Draves" <[email-masked]>
Date: Mon, 19 Aug 2002 08:36:12 -0700

> 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).

Really it should point to the Default Address Selection RFC, although I
suppose that would create an undesirable document dependency.

Rich

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 26 Aug 2002 13:47:12 -0400

I agree with Itojun I think?  I believe the way it should be is that once an address is deprecated no new existing connections should be started (via the SYN)  I think we want to keep the wording as SHOULD NOT or SHOULD if we change.  In case there is the non normal case that it must be permitted.  So I think the basic wording is correct?

/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 19, 2002 7:08 AM
> To: Robert Elz
> Cc: [email-masked]
> Subject: Re: need clarification of "deprecated" address 
> 
> 
> >No, I know you didn't.
> 
> >  |     i suggested we should refuse new incoming 
> connections (TCP SYN).
> 
> >Yes, that is what I am arguing against.
> 
> >The line of reasoning seems to be
> 
> >	if we accept a connection to a deprecated address, we may
> >	have to open a connection from a deprecated address later.
> >
> >	we're not allowed to open a connection from a deprecated address
> >
> >	hence we should not accept connections to deprecated addresses
> 
> 	FTP story was just an example.  independent from the 
> FTP story, i am
> 	- pointing out that the current text does not give any guidance
> 	  to incoming TCP SYN case, and
> 	- we should drop incoming TCP SYN to deprecated addresses.
> 
> itojun

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 26 Aug 2002 13:48:15 -0400

I think a bit more clarity on what "new" means would be useful for sure.  I don't see that as a showstopper for us and I think we are all in violent agreement here????

/jim

> Sent: Monday, August 19, 2002 7:39 AM
> To: Robert Elz
> Cc: Atsushi Onoe; [email-masked]
> >  | 	this may be an implementation issue, but who should decide it?
> >It was already decided long ago.   The doc may need to be 
> made clearer.
> 
> 	"who" means "userland, or kernel".
> 
> itojun

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 28 Aug 2002 19:28:02 -0400

Robert,

Not disagreeing there is affect to address selection.  But no one should assume address selection will be widely deployed at this time.  That remains to be seen.  I think it will personally.

My issue is what we do with a deprecated address in our stacks regarding behavior and that resolution is not driven by address selection.  That is all.

regards,
/jim

> From: Robert Elz [mailto:[email-masked]]
> Sent: Tuesday, August 27, 2002 9:30 AM
> To: Bound, Jim
> Cc: Richard Draves; [email-masked]; Atsushi Onoe;
> [email-masked]
>     Date:        Mon, 26 Aug 2002 13:50:27 -0400
>     From:        "Bound, Jim" <[email-masked]>
>     Message-ID:  
> <[email-masked]
> qcorp.net>
> 
> Jim, all of this was pretty much settled almost a week ago, 
> all that remains
> is to get the text modified (but as I don't think there's a 
> new version of
> this doc in the works right now, I'm not sure when that will happen).
> 
> Even the new text has been agreed, I believe.   But ...
> 
>   | this has nothing to do with default address selection in 
> the IP layer
> 
> The address selection draft is more than that, but "this" had 
> everything
> to do with address selection - the "default" case is the one where not
> using a deprecated address is the correct answer, in other 
> cases it isn't,
> and that's why perhaps mention about not using deprecated 
> addresses might
> be better in the default addr selection doc, and no-where else.
> Unfortunately while putting it there is easy (for Rich) that 
> doesn't by
> itself get rid of the text from 2462.   And that text was the problem.
> 
>   | Also the discussion is for incoming transport layer 
> connections for TCP,
> 
> Yes, but that was influenced by a decision made about what 
> was legal for
> outgoing connections, based upon one reading of the doc.   
> The implementation
> has been fixed since, and new text for the doc to avoid it in 
> future agreed.
> 
>   | SCTP, and I think we need to consider connectionless too.
> 
> Yes, all the same issues (approximately) apply to connectionless.
> 
>   | Sure for applications but I don't think that is the discussion.  
> 
> They were part of it.    You probably needed to read all of 
> the messages,
> more carefully, before replying.
> 
> kre
> 
>