Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Iljitsch van Beijnum]

On 15-jul-2005, at 3:25, Ned Freed wrote:


It would not make much sense, between 2 hosts you can already have
65536*65536 possible connections*, which should be more than
enough(tm) ;) I wonder if there are any hosts actually using more  
than

65536 connections at the same time.


True enough, however, you can only have 65536 connections to a  
single service

on a given port.


Sounds like an implementation limitation to me.

Demultiplexing should happen on source and destination IP addresses  
and source and destination port numbers. Assuming the server's IP  
address and port number are given, that allows for a 65536 sessions  
towards each possible IP address connected to the network. That  
should be enough, I'd think.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: A proposed experiment in narrative minutes of IESG meetings

[Brian E Carpenter]

Simon Josefsson wrote:

"Marshall Eubanks" <[EMAIL PROTECTED]> writes:



On Thu, 14 Jul 2005 18:08:45 +0200
Simon Josefsson <[EMAIL PROTECTED]> wrote:


Brian E Carpenter <[EMAIL PROTECTED]> writes:



We propose that, for an initial period of 6 months, a member of
the community will be added to regular IESG meetings as a "recording
secretary" who will write narrative minutes of the discussions,
which will be posted publicly after IESG review for accuracy.


Sounds useful to me.  How about actually recording the discussion too?
And publishing them as OGG or MP3.  Editing out personnel discussion
would still be possible.  All for the sake of transparency and
accountability.


My experience is that recordings tend to shut some people up.



My experience is that recordings tend to make people focus on facts,
rather than trying to win a discussion or furthering their own agenda.
If the IESG meetings are intended as service to the community, from
experts, that seem to be a good thing.



Plus, if they exist, they are subject to subpoena.



Is that a problem?  Not purely a rhetorical question.



The two points are linked. The IESG gets to make some decisions about
people. "X is a lousy WG chair, but Y is the only plausible replacement,
and she works for Z so would have a commercial interest in the
outcome. So we have to put up with X." I think people wouldn't say that
on a call that was being recorded for posterity, precisely because it might
be sub poenaed.

Whereas the narrative minutes would say
"The IESG discussed the Foobar WG and agreed with the AD's proposal to
continue with the current WG chair."

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: A proposed experiment in narrative minutes of IESG meetings

[Simon Josefsson]

Brian E Carpenter <[EMAIL PROTECTED]> writes:

> Simon Josefsson wrote:
>> "Marshall Eubanks" <[EMAIL PROTECTED]> writes:
>> 
>>>On Thu, 14 Jul 2005 18:08:45 +0200
>>> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>>>
Brian E Carpenter <[EMAIL PROTECTED]> writes:


>We propose that, for an initial period of 6 months, a member of
>the community will be added to regular IESG meetings as a "recording
>secretary" who will write narrative minutes of the discussions,
>which will be posted publicly after IESG review for accuracy.

Sounds useful to me.  How about actually recording the discussion too?
And publishing them as OGG or MP3.  Editing out personnel discussion
would still be possible.  All for the sake of transparency and
accountability.
>>>
>>>My experience is that recordings tend to shut some people up.
>> My experience is that recordings tend to make people focus on facts,
>> rather than trying to win a discussion or furthering their own agenda.
>> If the IESG meetings are intended as service to the community, from
>> experts, that seem to be a good thing.
>> 
>>>Plus, if they exist, they are subject to subpoena.
>> Is that a problem?  Not purely a rhetorical question.
>> 
>
> The two points are linked. The IESG gets to make some decisions about
> people. "X is a lousy WG chair, but Y is the only plausible replacement,
> and she works for Z so would have a commercial interest in the
> outcome. So we have to put up with X." I think people wouldn't say that
> on a call that was being recorded for posterity, precisely because it might
> be sub poenaed.
>
> Whereas the narrative minutes would say
> "The IESG discussed the Foobar WG and agreed with the AD's proposal to
> continue with the current WG chair."

The logical conclusion to that problem is to edit out those parts of
the recording before making it public.  Editing audio is roughly as
difficult as writing down narrative minutes these days.  That
filtering and editing process is required when writing minutes too, so
it is not like an entirely new process is required.  Listeners would
have to listen to the recording and read the minutes to get the
complete publicly available information.

Thanks,
Simon

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Meeting Locations

[Brian E Carpenter]

Clint,

Firstly, please note that this is now part of the IETF Administrative
Ditrector's responsibility. I've put him on copy.

Second, we all agree that locations should be chosen and announced
as early possible.

Third, there is a very high probability that IETF65 will be at a
US location and we have a host in view - but until that is fully
settled I don't think we can say in public.  I'm sure Ray will tell
us as soon as possible.

Brian


Clint Chaplin wrote:

How far in advance are the locations of IETF meetings determined?  Is
there any way to find out what the possible candidates are?

I'm having to budget travel for the next year, and knowing where IETF
65 will be held would help me a lot.



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Meeting Locations

[John C Klensin]

--On Friday, 15 July, 2005 11:59 +0200 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:

> Clint,
> 
> Firstly, please note that this is now part of the IETF
> Administrative
> Ditrector's responsibility. I've put him on copy.
> 
> Second, we all agree that locations should be chosen and
> announced
> as early possible.
> 
> Third, there is a very high probability that IETF65 will be at
> a
> US location and we have a host in view - but until that is
> fully
> settled I don't think we can say in public.  I'm sure Ray will
> tell
> us as soon as possible.

Brian and Ray,

Is it reasonable for us to hope that, as things settle down over
time, we can reasonably expect to get to the "meeting times and
locations known 18 months to two years out" status that has been
the target for some years?  Or, to put it differently, without
any unreasonable expectations about how quickly it is possible
to get back onto that basis, is it still the target and do you
consider that target plausible?

john






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: A proposed experiment in narrative minutes of IESG meetings

[Brian E Carpenter]

Simon Josefsson wrote:

Brian E Carpenter <[EMAIL PROTECTED]> writes:



Simon Josefsson wrote:


"Marshall Eubanks" <[EMAIL PROTECTED]> writes:



On Thu, 14 Jul 2005 18:08:45 +0200
Simon Josefsson <[EMAIL PROTECTED]> wrote:



Brian E Carpenter <[EMAIL PROTECTED]> writes:




We propose that, for an initial period of 6 months, a member of
the community will be added to regular IESG meetings as a "recording
secretary" who will write narrative minutes of the discussions,
which will be posted publicly after IESG review for accuracy.


Sounds useful to me.  How about actually recording the discussion too?
And publishing them as OGG or MP3.  Editing out personnel discussion
would still be possible.  All for the sake of transparency and
accountability.


My experience is that recordings tend to shut some people up.


My experience is that recordings tend to make people focus on facts,
rather than trying to win a discussion or furthering their own agenda.
If the IESG meetings are intended as service to the community, from
experts, that seem to be a good thing.



Plus, if they exist, they are subject to subpoena.


Is that a problem?  Not purely a rhetorical question.



The two points are linked. The IESG gets to make some decisions about
people. "X is a lousy WG chair, but Y is the only plausible replacement,
and she works for Z so would have a commercial interest in the
outcome. So we have to put up with X." I think people wouldn't say that
on a call that was being recorded for posterity, precisely because it might
be sub poenaed.

Whereas the narrative minutes would say
"The IESG discussed the Foobar WG and agreed with the AD's proposal to
continue with the current WG chair."



The logical conclusion to that problem is to edit out those parts of
the recording before making it public.  Editing audio is roughly as
difficult as writing down narrative minutes these days.  That
filtering and editing process is required when writing minutes too, so
it is not like an entirely new process is required.  Listeners would
have to listen to the recording and read the minutes to get the
complete publicly available information.


I'm sorry, I *really* don't think this would be practical. Editing written
notes is much easier and quicker then editing audio, and can be done
anywhere the scribe's laptop can be opened.

This would be one bridge too far for me.

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Brian E Carpenter]

Scott Bradner wrote:

works for me (assuming that you include non-IETF documents when you
say "IETF review documents")


In which case, what you last call is not the document itself but
what the IETF intends to say about it, and do about the related
IANA action.

That being so, I think we now have running code proof that this is
what the community wants.

Brian



Scott




From [EMAIL PROTECTED]  Thu Jul 14 18:12:46 2005

X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED] (Scott Bradner)
Cc: ietf@ietf.org
Subject: Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt
References: <[EMAIL PROTECTED]>
From: Sam Hartman <[EMAIL PROTECTED]>
Date: Thu, 14 Jul 2005 18:12:40 -0400
In-Reply-To: <[EMAIL PROTECTED]> (Scott
 Bradner's message of "Thu, 14 Jul 2005 12:52:38 -0400 (EDT)")
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

would it be reasonable to just say that we are going to always last
call IETF review documents?  Personally I'd approve of this option
unless people think it is too restrictive.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[Scott Bradner]

> In which case, what you last call is not the document itself but
> what the IETF intends to say about it, and do about the related
> IANA action.

just so

Scott

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Seeking reviewers for language tag registry docs in WG last call

[Brian E Carpenter]

Hi guys,

Until the WG has consensus, can you keep the discussion on
the WG list?

When there is draft ready for IETF Last Call, we can discuss
it here.

Thanks

Brian

JFC (Jefsey) Morfin wrote:

On 02:45 15/07/2005, Randy Presuhn said:

Please do not be misled by the domain name of 
http://rfc3066.org/review.htm
That site is not affiliated with the ltru WG or the 
[EMAIL PROTECTED]
mailing list that performs the language tag review function described 
in RFC 3066.



This is right. There are two doctrines.
- an exclusive one: to have a new RFC restricting the possibilities of 
RFC 3066 in term of language support
- an inclusive one: to keep RFC 3066 as a flexible base for innovation, 
and to accep the Draft in parallel



I think prospective reviewers' time would be much better spent looking at
the actual documents under WG last call, rather than trying to make 
sense of

the stuff at  http://rfc3066.org/review.htm



The "stuff" concerns considerations on IETF/ISO/UN relative 
authoritativeness, standard disclaimer on political aspects inovlved in 
multilingualism, compatibility between the IANA structure and ISO 
Registry standards, need of retro-compatibility with new propositions, etc.


During a WGLC all the last-call issues must be addressed by the WG. This 
is for me the only way to clarify these points while waiting the WG 
Charter to be analysed.



The documents under WG last call are
http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt
http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt

We'd prefer to have your comments on the documents themselves,
rather than reactions to Jefsey's sometimes over-heated polemic.



??? the question is to know if the general points _not_ mentionned into 
the Draft should be added to it, or belong to a separate Framework 
document?


Very dull and practical.
jfc 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Test version of the Parking Area

[Frank Ellermann]

Bill Fenner wrote:
 
> It should be working now.

Yes.  And what's the idea ?
  
So far I took e.g. "draft-crocker-abnf-rfc2234bis-00.txt",
removed "draft-" and "-00.txt" resulting in a fragment id.
"crocker-abnf-rfc2234bis", and added it to the queue URL:

http://www.rfc-editor.org/queue.html#crocker-abnf-rfc2234bis

And that's the position of 2234bis within its category
"non-WG standards track" (chronological).

For a new view on the editor queue it could be interesting
to split "blocked" I-Ds (= pending IANA or REF) from the
rest, sorting the rest chronologically, if that's the order
of processing.

Maybe you could add links to the second date (= "entered
the queue") to these fragments, e.g. link 2003-01-07 for
 to


Ugh, new rule, don't strip "draft-" for any "draft-ietf-".

Apparently that's the oldest "non-blocked" I-D, whatever
that means.  For a fairer view you might need the date of
the "unblocking".
   Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Test version of the Parking Area

[Bill Fenner]

>Yes.  And what's the idea ?

It's the IETF's statement about having approved the documents, as opposed
to the RFC Editor's statement about having the documents in the queue.
  
>So far I took e.g. "draft-crocker-abnf-rfc2234bis-00.txt",
>removed "draft-" and "-00.txt" resulting in a fragment id.

Unfortunately, whether or not you have to remove the "draft-" depends
on who added the document to the queue and when.  The RFC Editor said
they would be working on getting this consistent but for now it's not
very useful.

>And that's the position of 2234bis within its category
>"non-WG standards track" (chronological).

The primary key on the parking area is simply the date (and I'm
working on other sort orders).

  Bill

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Meeting Locations

[Spencer Dawkins]

There are a couple of helpful data points for many attendees. In my 
own case, knowing there are two North American meetings planned, or 
only one, in a given year tells me a lot about budgeting long before a 
specific location is announced.


Spencer

From: "Brian E Carpenter" <[EMAIL PROTECTED]>



Clint,

Firstly, please note that this is now part of the IETF 
Administrative

Ditrector's responsibility. I've put him on copy.

Second, we all agree that locations should be chosen and announced
as early possible.

Third, there is a very high probability that IETF65 will be at a
US location and we have a host in view - but until that is fully
settled I don't think we can say in public.  I'm sure Ray will tell
us as soon as possible.

Brian

Clint Chaplin wrote:
How far in advance are the locations of IETF meetings determined? 
Is

there any way to find out what the possible candidates are?

I'm having to budget travel for the next year, and knowing where 
IETF
65 will be held would help me a lot. 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: A proposed experiment in narrative minutes of IESG meetings

[John C Klensin]

--On Friday, 15 July, 2005 10:35 +0200 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:

>...
> Whereas the narrative minutes would say
> "The IESG discussed the Foobar WG and agreed with the AD's
> proposal to continue with the current WG chair."

Brian,

As part of the experiment, and in consultation with counsel if
needed, I would hope that the narrative minutes would push that
a bit harder, e.g., to

"The IESG discussed management issues with the Foobar WG
and agreed with the AD's proposal to monitor the
situation more intensely and continue with the current
WG chair."

Without getting into the personnel-related reasons for the
decision, that signals to the community that the AD, and the
IESG, are aware that there is a problem and plan to take some
additional measures to cope with it.   We need, I think, to know
that much; we don't need to know the details of why a different
course was not chosen.

Of course, at the risk of conflating threads, I would hope that,
any time a "X is lousy but there is no possible replacement"
situation arises, the cognizant body would ask itself and, to
the extent feasible, the relevant community, the meta question
of whether it is appropriate to continue the work if leadership
depth and interest is that shallow.  The answer to that question
may often be "yes" but it seems, IMO, that it is important that
it be asked.

It is precisely because the above concerns can be raised and
examined in this context --and cannot in the context of
decision-record minutes-- that causes me to think this
experiment is a wonderful idea.  I thank you and your IESG
colleagues for being willing to propose and consider it.

john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: A proposed experiment in narrative minutes of IESG meetings

[Simon Josefsson]

Brian E Carpenter <[EMAIL PROTECTED]> writes:

>>>The two points are linked. The IESG gets to make some decisions about
>>>people. "X is a lousy WG chair, but Y is the only plausible replacement,
>>>and she works for Z so would have a commercial interest in the
>>>outcome. So we have to put up with X." I think people wouldn't say that
>>>on a call that was being recorded for posterity, precisely because it might
>>>be sub poenaed.
>>>
>>>Whereas the narrative minutes would say
>>>"The IESG discussed the Foobar WG and agreed with the AD's proposal to
>>>continue with the current WG chair."
>> The logical conclusion to that problem is to edit out those parts of
>> the recording before making it public.  Editing audio is roughly as
>> difficult as writing down narrative minutes these days.  That
>> filtering and editing process is required when writing minutes too, so
>> it is not like an entirely new process is required.  Listeners would
>> have to listen to the recording and read the minutes to get the
>> complete publicly available information.
>
> I'm sorry, I *really* don't think this would be practical. Editing written
> notes is much easier and quicker then editing audio, and can be done
> anywhere the scribe's laptop can be opened.

It depends on the scribe I guess.  I would expect anyone who wanted to
do a decent job as a scribe would record the discussion and go over it
once or twice anyway.

But having one recording a year, like Sam suggested, would indeed be
useful too.  As noted, however, it would not have any significant
technical use, except as an introduction to the culture in IESG.

Thanks,
Simon

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[John C Klensin]

--On Friday, 15 July, 2005 01:20 +0100 David Hopwood
<[EMAIL PROTECTED]> wrote:

> The arguments for considering it to be in scope would have
> been:
> 
>   - the TCP and UDP "pseudo-headers" needed to be changed
> anyway to
> accomodate IPv6 addresses (see section 8.1 of RFC 2460);
> 
>   - the pressure on well-known port numbers was obvious at the
> time;
> 
>   - supporting 32-bit port numbers in IPv6 stacks could have
> been done
> at very little incremental cost;
> 
>   - a larger port space would have been an additional
> incentive to
> adopt IPv6;
> 
>   - more ambitious changes to TCP would have a low probability
> of
> adoption within a relevant timeframe;
> 
>   - it makes sense for the port number space to be the same
> size for
> UDP-over-IPv6 and TCP-over-IPv6.

And, for whatever it is worth, this is precisely why the "reg
policy" document tried to say "as soon as someone says
'scarcity', it is important to start thinking about the
appropriateness and mechanisms for an expansion plan".  Now, the
mechanism stated there may not have been appropriate, or the
language might have been poorly-chosen, but the underlying point
is "oh, we are running out, we need to get more and more
restrictive" is generally not a solution.  It may be a good
stopgap or conservation model while an alternative mechanism is
worked out (one could argue that CIDR bears exactly that
relationship to IPv6), but it is not a solution.  Of course, the
conclusion from that thinking process could be, in some cases
"there won't be a problem, ever, if we are reasonably
conservative".  But the evaluation is important and it is, IMO,
valuable to do it as soon as the signs or claim of scarcity
appear, not when we are looking at what gets the last two
possible allocations.

 john






___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Meeting Locations

[Brian E Carpenter]

My expectation is that we'll stick to the pattern of two N American
meetings plus one in another region - but meeting planning is an art,
not a science.

   Brian

Spencer Dawkins wrote:
There are a couple of helpful data points for many attendees. In my own 
case, knowing there are two North American meetings planned, or only 
one, in a given year tells me a lot about budgeting long before a 
specific location is announced.


Spencer

From: "Brian E Carpenter" <[EMAIL PROTECTED]>



Clint,

Firstly, please note that this is now part of the IETF Administrative
Ditrector's responsibility. I've put him on copy.

Second, we all agree that locations should be chosen and announced
as early possible.

Third, there is a very high probability that IETF65 will be at a
US location and we have a host in view - but until that is fully
settled I don't think we can say in public.  I'm sure Ray will tell
us as soon as possible.

Brian

Clint Chaplin wrote:


How far in advance are the locations of IETF meetings determined? Is
there any way to find out what the possible candidates are?

I'm having to budget travel for the next year, and knowing where IETF
65 will be held would help me a lot. 





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Meeting Locations

[Scott W Brim]

On Fri, Jul 15, 2005 05:27:45PM +0200, Brian E Carpenter allegedly wrote:
> My expectation is that we'll stick to the pattern of two N American
> meetings plus one in another region - but meeting planning is an art,
> not a science.

I like the deterministic formula based on the number of drafts
written.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Noel Chiappa]

> From: Iljitsch van Beijnum <[EMAIL PROTECTED]>

>> you can only have 65536 connections to a single service on a given
>> port.

> Demultiplexing should happen on source and destination IP addresses and
> source and destination port numbers. ... that allows for a 65536
> sessions towards each possible IP address connected to the network.

It depends on what protocol you are talking about.

For TCP, this is true: incoming packet demux is based on foreign address/port
as well as local port, so each local port could have (as you point out) up to
65K connections to any other IP address.

However, for UDP this is not the case; the base UDP protocol has no concept of
"connection", and demultiplexing is *supposed* to be done only on local port.
(Which is why TFTP has that funny little hop-step with port numbers when a
TFTP transfer starts.) So for UDP, each local port could only have one
"connection" at a time (and that's to the entire Internet, not per-host) -
unless, of course, the higher-level protocol running on top of UDP does some
sort of demultiplexing (which might use foreign host/port, of course).

However, not all implementations correctly implement this: for instance, I'm
rather embarassed to admit that when I recently looked at a TCP/IP I wrote
some years back, I discovered that the UDP layer used the exact same
demultiplexing code as TCP! Ooops...

Noel

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Iljitsch van Beijnum]

On 15-jul-2005, at 17:36, Noel Chiappa wrote:

Demultiplexing should happen on source and destination IP  
addresses and

source and destination port numbers. ... that allows for a 65536
sessions towards each possible IP address connected to the network.



It depends on what protocol you are talking about.


For TCP, this is true: incoming packet demux is based on foreign  
address/port
as well as local port, so each local port could have (as you point  
out) up to

65K connections to any other IP address.


Right.

However, for UDP this is not the case; the base UDP protocol has no  
concept of
"connection", and demultiplexing is *supposed* to be done only on  
local port.


For one-packet-in-each-direction protocols such as DNS this would be  
accurate (another reading of RFC 768 (got to love those two/three  
page RFCs) reveals that the source port is optional), but:


unless, of course, the higher-level protocol running on top of UDP  
does some

sort of demultiplexing (which might use foreign host/port, of course).


And if the source port isn't used in the first place, there isn't  
much need to increase the field.  :-)


Another observation: as far as I can tell, well known port numbers  
are always assigned for both TCP and UDP, even though only a small  
number of protocols runs over both TCP and UDP. Splitting up the  
number space between TCP and UDP would provide some relief,  
especially for UDP (the less used of the two).


For TCP, the issue is less critical as there are already other  
mechanisms that allow us to move away from well known port numbers.  
One is the SRV DNS record that I mentioned yesterday, but if you set  
your way back machine to 1988 you'll find RFC 1078 which accomplishes  
the same thing in a different way.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Ned Freed]

On 15-jul-2005, at 3:25, Ned Freed wrote:



>> It would not make much sense, between 2 hosts you can already have
>> 65536*65536 possible connections*, which should be more than
>> enough(tm) ;) I wonder if there are any hosts actually using more
>> than
>> 65536 connections at the same time.



> True enough, however, you can only have 65536 connections to a
> single service
> on a given port.



Sounds like an implementation limitation to me.


Reread my message. It is nothing of the sort.


Demultiplexing should happen on source and destination IP addresses
and source and destination port numbers. Assuming the server's IP
address and port number are given, that allows for a 65536 sessions
towards each possible IP address connected to the network.


This is the limit I'm talking about, which you now have agreed is a protocol
design limit and not an implementation limit.


That should be enough, I'd think.


And you'd be wrong. The specific case I've seen is with IMAP4. IMAP4 has the
characteristic that you often have a huge number of incoming connections, only
a few of which are active at any given time.

Designing servers to accomodate huge numbers of connections is a bit tricky,
but workable: You typically have to multiplex the connections onto a pool of
worker threads rather than having one thread per connection or one thread for
all connections. But the key point is that it can be done without exposing the
complexity to the people running the system.

The 65536 limit, OTOH, has to be dealt with by using multiple server IP
addresses, which in turn usually require multiple interfaces and configuration
trickery. This slops over to product and even user client configuration, making
things more complex and error prone.

Mind you, I'm not saying that TCP needs to be redesigned ASAP to  allow for a
larger number of source ports. IMO the pain would probably outweigh the gain.
But that doesn't mean nobody is hitting the 65536 limit imposed by source port
numbers. They are, it causes problems, and this needs to be kept in mind.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: A proposed experiment in narrative minutes of IESG meetings

[Spencer Dawkins]

Dear IESG,

I sent a private "thank you" to Brian replying to his original note, 
but wanted to say so in public.


Thank you.

Spencer

From: "John C Klensin" <[EMAIL PROTECTED]>



It is precisely because the above concerns can be raised and
examined in this context --and cannot in the context of
decision-record minutes-- that causes me to think this
experiment is a wonderful idea.  I thank you and your IESG
colleagues for being willing to propose and consider it.

   john 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Iljitsch van Beijnum]

On 15-jul-2005, at 18:11, Ned Freed wrote:


Demultiplexing should happen on source and destination IP addresses
and source and destination port numbers. Assuming the server's IP
address and port number are given, that allows for a 65536 sessions
towards each possible IP address connected to the network.


This is the limit I'm talking about, which you now have agreed is a  
protocol

design limit and not an implementation limit.


Sure.


That should be enough, I'd think.



And you'd be wrong.


Who, me? That can't be...


The specific case I've seen is with IMAP4. IMAP4 has the
characteristic that you often have a huge number of incoming  
connections, only

a few of which are active at any given time.


I know what you mean, I've seen my Mac generate more than a dozen  
simultaneous IMAP sessions on occasion. However, are you saying that  
ONE client would use more than 64k IMAP sessions? That would be  
inefficient, to say the least.


Also, since the clients don't tend to coordinate their port use, it's  
common for servers to see lots of sessions where both the destination  
port (duh, that's the well known one) and the source port are the  
same. (When people connect to the IMAP server after booting their  
source port is one of the first dozen or so that their OS uses.)  
Since the server address is also fixed under normal circumstances,  
the source address is a key ingredient in the demultiplexing.  
Fortunately, there are enough of those for this purpose, even in IPv4.


But that doesn't mean nobody is hitting the 65536 limit imposed by  
source port
numbers. They are, it causes problems, and this needs to be kept in  
mind.


If they are, they're probably using some kind of proxy or NAT setup,  
for instance, having SSL sessions decrypted and then forwarded to the  
actual server port, making all the sessions seem to come from the  
same address.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ned Freed]

Ned Freed wrote:
  Mind you, I'm not saying that TCP needs to be redesigned ASAP to  allow
> for a
> larger number of source ports. IMO the pain would probably outweigh the
> gain.
> But that doesn't mean nobody is hitting the 65536 limit imposed by
> source port
> numbers. They are, it causes problems, and this needs to be kept in mind.
>



Out of curiosity, doesn't SCTP have a bigger port space (or its
moral equivalent)? If so, would that be a better option?


I have in fact on several occasions proposed using SCTP as a transport for
various email services. I did so no so much to take advantage of the larger
port numbers, but because the multistream support SCTP provides could be
leveraged in several interesting ways. (In fact the multiplexing might
even lessen the need for so many connections.)

However, I've gotten very little traction for these suggestions in the past.
The biggest problem seems to be the lack of SCTP support in quite a few of the
stacks out there. And it is one thing for an application to tack on a layer on
top of TCP like TLS, quite another for an application to add a new network
transport. So the conclusion again seems to be that the costs are greater than
the benefits.

Ned


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ned Freed]

On 15-jul-2005, at 18:11, Ned Freed wrote:



> The specific case I've seen is with IMAP4. IMAP4 has the
> characteristic that you often have a huge number of incoming
> connections, only
> a few of which are active at any given time.



I know what you mean, I've seen my Mac generate more than a dozen
simultaneous IMAP sessions on occasion. However, are you saying that
ONE client would use more than 64k IMAP sessions?


I'm saying that one source system can generate more than 64K IMAP4 sessions.
These are systems running various sorts of proxies, so they are in effect
hosting many clients at once.


That would be
inefficient, to say the least.


It would be if it was a single client, I guess. But it isn't.


Also, since the clients don't tend to coordinate their port use, it's
common for servers to see lots of sessions where both the destination
port (duh, that's the well known one) and the source port are the
same. (When people connect to the IMAP server after booting their
source port is one of the first dozen or so that their OS uses.)
Since the server address is also fixed under normal circumstances,
the source address is a key ingredient in the demultiplexing.
Fortunately, there are enough of those for this purpose, even in IPv4.



> But that doesn't mean nobody is hitting the 65536 limit imposed by
> source port
> numbers. They are, it causes problems, and this needs to be kept in
> mind.



If they are, they're probably using some kind of proxy or NAT setup,
for instance, having SSL sessions decrypted and then forwarded to the
actual server port, making all the sessions seem to come from the
same address.


Exactly. SSL hardware is certainly one reason for such setups. Others include
webmail, content filters, content transformers, auditing/monitoring, and IMAP4
before SMTP coordination.

I actually don't recall a case where NAT was conflated into all this, but that
may well be due to my not having asked the right questions at the right
time.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D

[Bob Hinden]

David,


I was looking more for an explanation of how and why it was decided to
be out of scope.

The arguments for considering it to be in scope would have been:

 - the TCP and UDP "pseudo-headers" needed to be changed anyway to
   accomodate IPv6 addresses (see section 8.1 of RFC 2460);

 - the pressure on well-known port numbers was obvious at the time;

 - supporting 32-bit port numbers in IPv6 stacks could have been done
   at very little incremental cost;

 - a larger port space would have been an additional incentive to
   adopt IPv6;

 - more ambitious changes to TCP would have a low probability of
   adoption within a relevant timeframe;

 - it makes sense for the port number space to be the same size for
   UDP-over-IPv6 and TCP-over-IPv6.


It was for the pragmatic reason of not wanting to redesign IP and TCP at 
the same time.  This would have made the overall IPng effort much 
harder.  At the time, there wasn't a pressing need to redesign TCP.  I 
don't remember any detailed technical analysis.


Bob



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Iljitsch van Beijnum]

On 15-jul-2005, at 19:14, Ned Freed wrote:


If they are, they're probably using some kind of proxy or NAT setup,
for instance, having SSL sessions decrypted and then forwarded to the
actual server port, making all the sessions seem to come from the
same address.


Exactly. SSL hardware is certainly one reason for such setups.  
Others include
webmail, content filters, content transformers, auditing/ 
monitoring, and IMAP4

before SMTP coordination.


Ah, the plot thickens.

A good solution here would be a private protocol extension between  
the different hosts that provide part of the service. Always good  
when you don't have to upgrade the entire internet to solve the  
problem at hand.  :-)



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Juergen Schoenwaelder]

On Fri, Jul 15, 2005 at 09:58:29AM -0700, Ned Freed wrote:

> >Out of curiosity, doesn't SCTP have a bigger port space (or its
> >moral equivalent)? If so, would that be a better option?
> 
> I have in fact on several occasions proposed using SCTP as a transport for
> various email services. I did so no so much to take advantage of the larger
> port numbers, but because the multistream support SCTP provides could be
> leveraged in several interesting ways. (In fact the multiplexing might
> even lessen the need for so many connections.)

Ehem, where is this larger port number? The port numbers I see in
section 3.1 of RFC 2960 seem to be 16 bit.

/js

-- 
Juergen Schoenwaelder   International University Bremen
 P.O. Box 750 561, 28725 Bremen, Germany

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D

[John C Klensin]

--On Friday, 15 July, 2005 10:31 -0700 Bob Hinden
<[EMAIL PROTECTED]> wrote:

> It was for the pragmatic reason of not wanting to redesign IP
> and TCP at the same time.  This would have made the overall
> IPng effort much harder.  At the time, there wasn't a pressing
> need to redesign TCP.  I don't remember any detailed technical
> analysis.

Does this discussion suggest that it is time to start taking a
look at TCPng?  If not now, at some point in the future that we
can anticipate?

(those are questions, not proposals, requests, or statements of
belief)

john



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D

[John Day]

Does this discussion suggest that it is time to start taking a
look at TCPng?  If not now, at some point in the future that we
can anticipate?

(those are questions, not proposals, requests, or statements of
belief)


Perhaps, but aren't we about 30 years late in getting rid of the 
kludge of well-known sockets?  Perhaps we should start solving 
problems instead of prolonging the agony.


Take care,
John

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ned Freed]

On 15-jul-2005, at 19:14, Ned Freed wrote:



>> If they are, they're probably using some kind of proxy or NAT setup,
>> for instance, having SSL sessions decrypted and then forwarded to the
>> actual server port, making all the sessions seem to come from the
>> same address.



> Exactly. SSL hardware is certainly one reason for such setups.
> Others include
> webmail, content filters, content transformers, auditing/
> monitoring, and IMAP4
> before SMTP coordination.



Ah, the plot thickens.



A good solution here would be a private protocol extension between
the different hosts that provide part of the service. Always good
when you don't have to upgrade the entire internet to solve the
problem at hand.  :-)


We already use this trick in a couple of places. But it only works when the
components all come from the same vendor. In many cases they don't. For
example, we often see our IMAP server used with someone else's webmail
interface.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Test version of the Parking Area

[Frank Ellermann]

Bill Fenner wrote:
 
 [  ]
> whether or not you have to remove the "draft-" depends on
> who added the document to the queue and when.  The RFC
> Editor said they would be working on getting this consistent

Let's hope that they settle on "keep the draft- prefix as is",
IIRC fragment id.s must start with an alpha, "draft-" is alpha.

 [  ]
> I'm working on other sort orders

Neither "REF" nor "IANA" in the "state" column before the date
could be very interesting.  Or some statistics, but I guess
you already have that elsewhere.
Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6 (was: I-D

[John C Klensin]

--On Friday, 15 July, 2005 13:54 -0400 John Day
<[EMAIL PROTECTED]> wrote:

>> 
>> Does this discussion suggest that it is time to start taking a
>> look at TCPng?  If not now, at some point in the future that
>> we can anticipate?
>> 
>> (those are questions, not proposals, requests, or statements
>> of belief)
> 
> Perhaps, but aren't we about 30 years late in getting rid of
> the kludge of well-known sockets?  Perhaps we should start
> solving problems instead of prolonging the agony.

While I'm not sure I quite share your conclusion about ports and
well-known sockets (I can see some tradeoffs in that area), you
will note that I said "take a look at TCPng" not "make the port
number field wider".

best,
john


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Michael Thomas]

Ned Freed wrote:
 Mind you, I'm not saying that TCP needs to be redesigned ASAP to  allow

for a
larger number of source ports. IMO the pain would probably outweigh the 
gain.
But that doesn't mean nobody is hitting the 65536 limit imposed by 
source port

numbers. They are, it causes problems, and this needs to be kept in mind.



Out of curiosity, doesn't SCTP have a bigger port space (or its
moral equivalent)? If so, would that be a better option?

Mike

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Hallam-Baker, Phillip]

It seems to me that the underlying problem here is that fixed port
numbers is not really the right solution to the protocol identification
problem.

When this was first proposed the number of machines on the Internet was
small and there was no DNS, only the host file.

The port number allocation scheme is really trying to do something that
should be done by the naming infrastructure. This is what SRV is for.
With SRV there is no longer any need for new protocol port assignments.
Protocol designers should be told to apply for an SRV prefix instead.

There are certain limitations to the SRV prefix scheme but these are
entirely fixable. All we actually need is one new RR to allow one level
of indirection to be introduced. With that in place it is possible to
use prefixed SRV records in place of port assignments and prefixed TXT
records as a means of expressing protocol configuration information.


Incidentially with these changes in place the DNS then provides all the
infrastructure that is required to deploy Web Services. UDDI becomes
superfluous. Existing deployed infrastructures such as HTTP and SMTP can
be developed in ways that are architecturally equivalent to the WS-*
approach.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Port numbers and IPv6

[Hallam-Baker, Phillip]

> I'm saying that one source system can generate more than 64K 
> IMAP4 sessions. These are systems running various sorts of 
> proxies, so they are in effect hosting many clients at once.

True, but if we are running IPv6 then surely the solution to this
problem would be to simply request some number of additional IP address
allocations via DHCP?

This is already done in the IPv4 world, it can be done in the IPv6
world.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ken Raeburn]

On Jul 15, 2005, at 11:59, Iljitsch van Beijnum wrote:
For TCP, the issue is less critical as there are already other 
mechanisms that allow us to move away from well known port numbers. 
One is the SRV DNS record that I mentioned yesterday, but if you set 
your way back machine to 1988 you'll find RFC 1078 which accomplishes 
the same thing in a different way.


Actually, it looks like 1078 (TCPMUX) basically runs everything over a 
connection to TCP port 1, so instead of limiting the connections to a 
given service from a single source IP address, you'd be limiting the 
connections to all multiplexed services, together, from a single source 
IP address.  ("Sorry, you can't telnet in, you've got too many IMAP 
sessions open.")


Now, if you ran TCPMUX on all 64K ports


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Iljitsch van Beijnum]

On 15-jul-2005, at 21:05, Ken Raeburn wrote:

For TCP, the issue is less critical as there are already other  
mechanisms that allow us to move away from well known port  
numbers. One is the SRV DNS record that I mentioned yesterday, but  
if you set your way back machine to 1988 you'll find RFC 1078  
which accomplishes the same thing in a different way.


Actually, it looks like 1078 (TCPMUX) basically runs everything  
over a connection to TCP port 1, so instead of limiting the  
connections to a given service from a single source IP address,  
you'd be limiting the connections to all multiplexed services,  
together, from a single source IP address.  ("Sorry, you can't  
telnet in, you've got too many IMAP sessions open.")



Now, if you ran TCPMUX on all 64K ports


Yes, that could be made to work... I don't think many clients  
implement it, though, although I seem to remember that at least one  
incarnation of inetd did/does.


Anyway, RFC 1078 doesn't solve the "many sessions between two  
addresses" issue, but I was talking about running out of well known  
port numbers here.


Unless I'm mistaken, SRV records can solve both (to some degree, you  
wouldn't want to have _huge_ amounts of DNS records for one service)  
since you can point a client to several addresses and/or ports.  
(Phillip, wat is the issue with SRV that you feel needs fixing?)


When I was talking about a private protocol extension between the  
hosts involved earlier, I was being imprecise: what I meant was that  
an extension to TCP could be created that allows for more port  
numbers, and that the two hosts involved could use such an extension  
between them. The "private" part wouldn't be the nature of the  
extension, but the fact that the actual clients don't have to be  
involved. As long as the component vendors all implement the  
extension, that would be enough.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Jeffrey Hutzelman]

On Friday, July 15, 2005 11:48:28 AM -0700 "Hallam-Baker, Phillip" 
<[EMAIL PROTECTED]> wrote:



It seems to me that the underlying problem here is that fixed port
numbers is not really the right solution to the protocol identification
problem.

When this was first proposed the number of machines on the Internet was
small and there was no DNS, only the host file.

The port number allocation scheme is really trying to do something that
should be done by the naming infrastructure. This is what SRV is for.
With SRV there is no longer any need for new protocol port assignments.
Protocol designers should be told to apply for an SRV prefix instead.


Agree, for the most part.  Fixed port numbers do have some operational 
advantages, though...


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Port numbers and IPv6 (was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Hallam-Baker, Phillip]

> From: Jeffrey Hutzelman [mailto:[EMAIL PROTECTED] 

> On Friday, July 15, 2005 11:48:28 AM -0700 "Hallam-Baker, Phillip" 
> <[EMAIL PROTECTED]> wrote:

> Agree, for the most part.  Fixed port numbers do have some 
> operational 
> advantages, though...

They certainly have operational advantages for managers of firewalls
that don't have the ability to perform filtering that is any more
specific.

And this had led protocol designers to run every new protocol over port
80 using the firewall bypass protocol HTTP.


One nice feature of using DNS is that it means that you can perform a
lot of control through the signalling channel alone. 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Noel Chiappa]

> From: Ned Freed <[EMAIL PROTECTED]>

Let me make sure I understand you here:

> IMAP4 has the characteristic that you often have a huge number of
> incoming connections, only a few of which are active at any given time.
> Designing servers to accomodate huge numbers of connections is a bit
> tricky, but workable: ...
> The 65536 limit, OTOH, has to be dealt with by using multiple server IP
> addresses, which in turn usually require multiple interfaces ...
> ... that doesn't mean nobody is hitting the 65536 limit imposed by
> source port numbers. They are, it causes problems

You're saying that there are servers which have close to (or more) than 65K
connections to a *single client IP address* (i.e. it may be a NAT, with a
number of hosts behind it)? (If a server is talking to a number of different
client IP addresses, it can have up to 65K connections to *each*.)

Noel

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ned Freed]

> > From: Ned Freed <[EMAIL PROTECTED]>

> Let me make sure I understand you here:

> > IMAP4 has the characteristic that you often have a huge number of
> > incoming connections, only a few of which are active at any given time.
> > Designing servers to accomodate huge numbers of connections is a bit
> > tricky, but workable: ...
> > The 65536 limit, OTOH, has to be dealt with by using multiple server IP
> > addresses, which in turn usually require multiple interfaces ...
> > ... that doesn't mean nobody is hitting the 65536 limit imposed by
> > source port numbers. They are, it causes problems

> You're saying that there are servers which have close to (or more) than 65K
> connections to a *single client IP address* (i.e. it may be a NAT, with a
> number of hosts behind it)? (If a server is talking to a number of different
> client IP addresses, it can have up to 65K connections to *each*.)

Yes, that is exactly what I am saying (now for the third time).

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Noel Chiappa writes
:
>> From: Ned Freed <[EMAIL PROTECTED]>
>
>Let me make sure I understand you here:
>
>> IMAP4 has the characteristic that you often have a huge number of
>> incoming connections, only a few of which are active at any given time.
>> Designing servers to accomodate huge numbers of connections is a bit
>> tricky, but workable: ...
>> The 65536 limit, OTOH, has to be dealt with by using multiple server IP
>> addresses, which in turn usually require multiple interfaces ...
>> ... that doesn't mean nobody is hitting the 65536 limit imposed by
>> source port numbers. They are, it causes problems
>
>You're saying that there are servers which have close to (or more) than 65K
>connections to a *single client IP address* (i.e. it may be a NAT, with a
>number of hosts behind it)? (If a server is talking to a number of different
>client IP addresses, it can have up to 65K connections to *each*.)
>

Ned isn't the first person I've heard this observation from.  Yes, 
there are some really large-scale systems that run into this limit.

Sure, there are work-arounds, such as assigning multiple IP addresses 
to the server and using DNS-based load balancing.  That doesn't change 
the fact that the basic design has run afoul of an address space limit.

Circa 1974, in a computer architecture class, I heard Fred Brooks point
out that *every* successful computer design eventually ran out of address 
space.  The same applies to network protocols.


--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Noel Chiappa]

> From: Ned Freed <[EMAIL PROTECTED]>

>> You're saying that there are servers which have close to (or more)
>> than 65K connections to a *single client IP address* (i.e. it may be a
>> NAT, with a number of hosts behind it)?

> Yes, that is exactly what I am saying

Wow. Can you tell us a little bit about what those client sites look like?

(Not the servers; I'm curious about the things at the far end which are
generating that many client connections. They must be huge NAT boxes, no? I
have a hard time conceiving of a single computer generating that many client
instances.)

Noel

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Stephen Sprunk]

Thus spake "Noel Chiappa" <[EMAIL PROTECTED]>

   > From: Ned Freed <[EMAIL PROTECTED]>

Let me make sure I understand you here:

   > IMAP4 has the characteristic that you often have a huge number
   > of incoming connections, only a few of which are active at any
   > given time.  Designing servers to accomodate huge numbers of
   > connections is a bit tricky, but workable: ...
   > The 65536 limit, OTOH, has to be dealt with by using multiple
   > server IP addresses, which in turn usually require multiple
   > interfaces ...
   > ... that doesn't mean nobody is hitting the 65536 limit imposed by
   > source port numbers. They are, it causes problems

You're saying that there are servers which have close to (or more)
than 65K connections to a *single client IP address* (i.e. it may be a
NAT, with a number of hosts behind it)? (If a server is talking to a
number of different client IP addresses, it can have up to 65K
connections to *each*.)


That assumes the client is directly talking to the IMAP server.  Some 
servers are behind an "SSL accelerator" such that all connections come from 
a single IP address, so only 64k clients are possible.  Other servers may be 
behind a webmail application, with the same effect.


The number of folks experiencing this has to be pretty low, but it'd be a 
severe problem for them.


S

Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov 



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ned Freed]

> > From: Ned Freed <[EMAIL PROTECTED]>

> >> You're saying that there are servers which have close to (or more)
> >> than 65K connections to a *single client IP address* (i.e. it may be a
> >> NAT, with a number of hosts behind it)?

> > Yes, that is exactly what I am saying

> Wow. Can you tell us a little bit about what those client sites look like?

Again, these sorts of boxes are proxies of one sort or another. The actual
functionality they provide varies considerably: Some are HTTP to email gateways
(webmail), others do content transform or filtering, some do archiving, some
attach security layers like TLS, and some do protocol-specific hackery like the
bookkeeping necessary for IMAP4 before SMTP. A lot of the time the proxies and
message stores run software from the same vendor, but fairly often they do not.

Typical hardware for something like this is a midrange box with a couple of
fast CPUs, fast network hardware, and possibly crypto addons. Fast high
bandwidth disk is unnecessary. We also find that these proxies don't parallize
as well as you might hope, so the big boxes with lots of CPUs aren't worth it.
YMMV of course, especially on how many CPUs are useful.

(IMAP4 store machines are of course a very different matter. In particular,
heavy duty disk subsystems are essential there.)

> (Not the servers; I'm curious about the things at the far end which are
> generating that many client connections. They must be huge NAT boxes, no? I
> have a hard time conceiving of a single computer generating that many client
> instances.)

As I said before, I haven't seen NAT as part of this picture, but this may be
due to my own ignorance of all the things being done in these setups. As it
happens I spend most of my time on the SMTP side of the equation, and SMTP,
unlike IMAP4, is characterized by short-lived connections as well as the
ability in most cases to rack-and-stack both destination servers and proxy
intermediaries. The 65536 connection limit is a nonissue for SMTP AFAIK.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Masataka Ohta]

Steven M. Bellovin wrote:

> Circa 1974, in a computer architecture class, I heard Fred Brooks point
> out that *every* successful computer design eventually ran out of address 
> space.  The same applies to network protocols.

An interesting theory.

It explains why IPv6 can't be successful.

Masataka Ohta



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Ned Freed]

> On Fri, Jul 15, 2005 at 09:58:29AM -0700, Ned Freed wrote:

> > >Out of curiosity, doesn't SCTP have a bigger port space (or its
> > >moral equivalent)? If so, would that be a better option?
> >
> > I have in fact on several occasions proposed using SCTP as a transport for
> > various email services. I did so no so much to take advantage of the larger
> > port numbers, but because the multistream support SCTP provides could be
> > leveraged in several interesting ways. (In fact the multiplexing might
> > even lessen the need for so many connections.)

> Ehem, where is this larger port number? The port numbers I see in
> section 3.1 of RFC 2960 seem to be 16 bit.

I haven't looked at this in several years, but my recollection is that the port
number space was larger. Faultly memory, or maybe that was in some draft and
dropped from the final version.

Ned

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Spencer Dawkins]

It would be OK if someone smart responded to this posting, but until 
they show up, http://www.ietf.org/rfc/rfc2960.txt is showing


- a 16-bit source and destination port numbers in the common header 
(3.1), AND


- a 16-bit stream identifier (3.3.1), AND

- a 32-bit Payload Protocol Identifier (3.3.1)

so there seems to be a large number of bits to identify a bunch of 
different "connections" and/or "protocols" in SCTP.


Ned, could you be remembering the PPI?

To be honest, I believe all the SCTP network traces I've seen had 
zeros in both the stream identifier and PPI, but the bits are there...


Spencer



> >Out of curiosity, doesn't SCTP have a bigger port space (or its
> >moral equivalent)? If so, would that be a better option?
>
> I have in fact on several occasions proposed using SCTP as a 
> transport for
> various email services. I did so no so much to take advantage of 
> the larger
> port numbers, but because the multistream support SCTP provides 
> could be
> leveraged in several interesting ways. (In fact the multiplexing 
> might

> even lessen the need for so many connections.)



Ehem, where is this larger port number? The port numbers I see in
section 3.1 of RFC 2960 seem to be 16 bit.


I haven't looked at this in several years, but my recollection is 
that the port
number space was larger. Faultly memory, or maybe that was in some 
draft and

dropped from the final version.

Ned 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Masataka Ohta writes:
>Steven M. Bellovin wrote:
>
>> Circa 1974, in a computer architecture class, I heard Fred Brooks point
>> out that *every* successful computer design eventually ran out of address 
>> space.  The same applies to network protocols.
>
>An interesting theory.
>
>It explains why IPv6 can't be successful.

Nice line.  I don't agree with either your conclusion or your 
sentiments, but it is definitely a nice line.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, "Spencer Dawkins" writes:
>It would be OK if someone smart responded to this posting, but until 
>they show up, http://www.ietf.org/rfc/rfc2960.txt is showing
>
>- a 16-bit source and destination port numbers in the common header 
>(3.1), AND
>
>- a 16-bit stream identifier (3.3.1), AND
>
>- a 32-bit Payload Protocol Identifier (3.3.1)
>
>so there seems to be a large number of bits to identify a bunch of 
>different "connections" and/or "protocols" in SCTP.
>
>Ned, could you be remembering the PPI?
>
>To be honest, I believe all the SCTP network traces I've seen had 
>zeros in both the stream identifier and PPI, but the bits are there...
>

If nothing else, with SCTP a single client could open multiple streams 
on one connection, rather than use multiple connections.  

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: I-D ACTION:draft-narten-iana-considerations-rfc2434bis-02.txt

[C. M. Heard]

On Fri, 15 Jul 2005, Brian E Carpenter wrote:
> Scott Bradner wrote:
> > Sam Hartman wrote:
> > > would it be reasonable to just say that we are going to
> > > always last call IETF review documents?  Personally I'd
> > > approve of this option unless people think it is too
> > > restrictive.
> >
> > works for me (assuming that you include non-IETF documents
> > when you say "IETF review documents")
> 
> In which case, what you last call is not the document itself but
> what the IETF intends to say about it, and do about the related
> IANA action.
> 
> That being so, I think we now have running code proof that this
> is what the community wants.

To make sure I understand what is being said here, is the proposal
that a Last Call would be required for the policies labelled "IETF
Review" and "IESG Approval"?  That seems reasonable to me.  And if a
last call requirement is added, I don't think there is a reaon any
more to change the name to "IETF Review" from "IETF Consensus".

I would be less supportive of a proposal to require Last Call in
connection with the "Specification Required" and "RFC Required"
assignment policies.  That seems too heavyweight.  However, I do
think that it would be reasonable to require that the supporting
documents be reviewed by a designated expert to verify that it they
are sufficiently clear to make possible interoperability between
independent implementations.

//cmh


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Port numbers and IPv6

[John]

Which is exactly the point.

John

- Original message -
From:Steven M. Bellovin  <[EMAIL PROTECTED]>
To:Spencer Dawkins <[EMAIL PROTECTED]>
Cc:IETF Discussion 
Subject:Re: Port numbers and IPv6
In message <[EMAIL PROTECTED]>, "Spencer Dawkins" writes:
>It would be OK if someone smart responded to this posting, but until 
>they show up, http://www.ietf.org/rfc/rfc2960.txt is showing
>
>- a 16-bit source and destination port numbers in the common header 
>(3.1), AND
>
>- a 16-bit stream identifier (3.3.1), AND
>
>- a 32-bit Payload Protocol Identifier (3.3.1)
>
>so there seems to be a large number of bits to identify a bunch of 
>different "connections" and/or "protocols" in SCTP.
>
>Ned, could you be remembering the PPI?
>
>To be honest, I believe all the SCTP network traces I've seen had 
>zeros in both the stream identifier and PPI, but the bits are there...
>

If nothing else, with SCTP a single client could open multiple streams 
on one connection, rather than use multiple connections.  

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf