Subject: Re: I-D ACTION:draft-klensin-iana-reg-policy-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jul 2005 16:57:58 +0200

General AD hat on:

I'm concerned that since rfc2434bis is in progress, any changes to
RFC 2434 should be made in that draft, not by an additional document.
Otherwise we will end up with a patchwork quilt of documents.

So I'd encourage the authors of iana-reg-policy to figure out where
their ideas would impact draft-narten-iana-considerations-rfc2434bis,
and as the saying goes "send text."

General AD hat off:

1. I agree with those who've said that we can't reasonably make
blanket retroactive changes to the intent of previous
IANA Considerations based on or citing RFC 2434. We can clearly
change the intent of future IANA Considerations (see previous
comment from the AD :-). But if existing, published documents
need to change (2780 to take an example) I think they have to
be changed explicitly.

2. It's easy to say that if a namespace is too small, we should
make it bigger. But, to take a recently contentious example,
there's a *reason* the IPv6 option field is only 3+5 bits long.
It wasn't an idle choice. It was to keep the IPv6 header as
short as possible and as nicely aligned as possible, for the benefit
of hardware designers and wirless networks in particular.
There was also a *reason* the diffserv code point was limited to
6 bits - as above, plus the fact that the ECN folk really needed
the other two bits.

So clearly, these small fields need prudent stewardship.

As a matter of fact, I can make an argument for prudent stewardship
in seemingly much larger fields. 32 bits seemed like a lot in 1980,
no doubt; 128 bits seemed like a lot in 1995. But see
draft-narten-iana-rir-ipv6-considerations-00.txt for why even
a 128 bit field needs prudent stewardship. And even the rather
large domain name space turns out to need prudent stewardship,
as Vint knows only too well.

So however large the namespace gets, it needs prudent stewardship.

I can't disagree that namespaces should be as large as reasonably
possible on engineering grounds. But actually extending a deployed
namespace is a massive undertaking. A good example is the BGP4 AS
number space - we've known for years that it is filling up, but the
deployment effort involved in expanding it has prevented any action.

So even if we can theoretically expand the namespace, it needs prudent
stewardship in practice.

3. Thus I come to the key question - how high should the bar be for
assignments in clearly constrained namespaces? This month's poster
child is IPv6 option numbers, but at an even more basic level, we
should probably be more worried about port numbers, where we seem
pretty close to running out of well-known numbers, and moving along
nicely through the registered port numbers.

I'm on the side of fairly rigorous review in these constrained spaces.
With the experience of the Larry Roberts request, I actually think
RFC 2780 is too lax - it would be better if IETF Review (in rfc2434bis
terminology) was required for option numbers.

Contrary to what I understand the present draft to mean, I think
that  for some very critical namespaces, such as IP header fields,
that may have fundamental impact on packet flows, a technical
review of the proposed usage of the parameter is *always*
required before an assignment, regardless of scarcity.

Clarity of definition is *not* enough to justify a registration;
we also need to agree as a community that the proposed usage will
not be a cause of collateral damage to the Internet. There's every
reason that the same standard should apply to specifications
developed outside the IETF exactly as to IETF documents.

For the more critical namespaces covered by 2780, I am quite sure this
applies. There can be other namespaces where it certainly doesn't.
I think we should concentrate on getting the definitions in 2434bis
right. I also think an update of 2780 is needed in the light of
experience.

    Brian

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Nick Staff" <[email-masked]>
Date: Wed, 13 Jul 2005 09:33:30 -0700

Comments inline...

> 
> General AD hat on:
> 
> I'm concerned that since rfc2434bis is in progress, any 
> changes to RFC 2434 should be made in that draft, not by an 
> additional document.
> So I'd encourage the authors of iana-reg-policy to figure out 
> where their ideas would impact 
> draft-narten-iana-considerations-rfc2434bis,
> 1. I agree with those who've said that we can't reasonably 
> make blanket retroactive changes to the intent of previous 
> IANA Considerations based on or citing RFC 2434. We can 
> clearly change the intent of future IANA Considerations (see 
> previous comment from the AD :-). But if existing, published 
> documents need to change (2780 to take an example) I think 
> they have to be changed explicitly.
> 
> 2. It's easy to say that if a namespace is too small, we 
> should make it bigger. But, to take a recently contentious 
> example, there's a *reason* the IPv6 option field is only 3+5 
> bits long.
> short as possible and as nicely aligned as possible, for the 
> benefit of hardware designers and wirless networks in particular.
> 6 bits - as above, plus the fact that the ECN folk really 
> needed the other two bits.
> 
> As a matter of fact, I can make an argument for prudent 
> stewardship in seemingly much larger fields. 32 bits seemed 
> like a lot in 1980, no doubt; 128 bits seemed like a lot in 
> 1995. But see 
> a 128 bit field needs prudent stewardship. And even the 
> rather large domain name space turns out to need prudent 
> stewardship, as Vint knows only too well.
> 
> I can't disagree that namespaces should be as large as 
> reasonably possible on engineering grounds. But actually 
> extending a deployed namespace is a massive undertaking. A 
> good example is the BGP4 AS number space - we've known for 
> years that it is filling up, but the deployment effort 
> involved in expanding it has prevented any action.
> 
> So even if we can theoretically expand the namespace, it 
> needs prudent stewardship in practice.
> 
> 3. Thus I come to the key question - how high should the bar 
> be for assignments in clearly constrained namespaces? This 
> month's poster child is IPv6 option numbers, but at an even 
> more basic level, we should probably be more worried about 
> port numbers, where we seem pretty close to running out of 
> well-known numbers, and moving along nicely through the 
> registered port numbers.

Regarding port assignment - I know what I'm about to suggest is somewhat
mickey-mouse (and could be interpreted as inviting self-assignment of
ports), but maybe we could make a distinction between the port ranges used
by system processes and the port ranges used by applications (by application
I mean software that is not stand alone and must run on top of another
system like an OS).  My only thought behind this is that we could minimize
critical conflicts because an application developer who was denied their
port request would at least know not to self-assign a port from the system
range because there would be no end user remediation of conflicts, whereas
if they picked from the application range, at least they know there'd always
be a workaround to conflicts in the vein of "you can't run my app while
you're running app x".  Again this is not to encourage self-assignment, but
to make it a little less problematic when it happens.

This is pretty off the cuff so if it's utterly stupid please treat it like a
brainstorming session and don't forever write me off as an idiot (if you
haven't already).

Thanks,

Nick Staff 
> With the experience of the Larry Roberts request, I actually 
> think RFC 2780 is too lax - it would be better if IETF Review 
> (in rfc2434bis
> Contrary to what I understand the present draft to mean, I 
> think that  for some very critical namespaces, such as IP 
> header fields, that may have fundamental impact on packet 
> flows, a technical review of the proposed usage of the 
> parameter is *always* required before an assignment, 
> regardless of scarcity.
> 
> Clarity of definition is *not* enough to justify a 
> registration; we also need to agree as a community that the 
> proposed usage will not be a cause of collateral damage to 
> the Internet. There's every reason that the same standard 
> should apply to specifications developed outside the IETF 
> exactly as to IETF documents.
> 
> For the more critical namespaces covered by 2780, I am quite 
> sure this applies. There can be other namespaces where it 
> certainly doesn't.
> I think we should concentrate on getting the definitions in 
> 2434bis right. I also think an update of 2780 is needed in 
> the light of experience.
> 
>     Brian
> 
>

---

From: Hans Kruse <[email-masked]>
Date: Wed, 13 Jul 2005 12:49:55 -0400

Sigh.  We keep hitting the same fundamental, philosophical, 
disagreement here.  Your wording may, however, leave room for 
compromise:

I think everyone agrees that clear documentation must exist, and be 
stable.  If not an RFC, a standards document from another organization, 
etc.

For limited option spaces, "stewardship" is needed, but what does this 
mean?  The document(s) being revised/created should give some guidance 
to the community on how to use "percentage of space free" and/or "rate 
of consumption" to make reasonably consistent choices.

Then there is "Technical Review"; I actually agree that a level of such 
review is required, but is must be LIMITED (unless of course the 
protocol itself is being IETF reviewed).  In a case like the one that 
triggered this debate, the review needs to include only:

1. If the option appears in a packet, will there be any possible 
negative impact on a network element that has no code to process the 
option.

2. If option space is limited, does the documentation suggest that 
deployment will actually take place (lets not assign limited codes to 
high school science projects).

That is it!  I fundamentally disagree with "There's every reason that 
the same standard should apply to specifications developed outside the 
IETF exactly as to IETF documents" for the simple reason that it is 
non-enforceable.  Beyond stewardship of limited code point space, I see 
no justification for the IETF having veto power over standards being 
developed to use public standards like IP.  The fact that such 
independent developments are possible is at the heart of the success of 
the Internet.

Do we really think there is or will be a rush to standardize IETF-like 
protocols in TIA, ITU, etc.? I don't think so unless the IETF really 
falls on its face as far as cranking out well-engineered solutions.

No, the little bit of "competition" will come in cases like this one, 
where a protocol is designed for a corner case in an organization with 
expertise for that corner case.  Again, as has happened here, the IETF 
probably does not have the right set of expertise to fully review the 
protocol, and it should not feel the need to do so.

It seems that you want a review of "is this protocol safe to deploy on 
the Internet"?  I can see the reasoning behind that, but I think the 
code point assignment review is the wrong place.  Assume for a moment 
that the outside request passes all the criteria above (well 
documented, no shortage, code point can be safely ignored by 
non-participating elements).  Lets further assume that we (IETF, IESG, 
...) "don't like" the protocol, or have insufficient expertise/time to 
evaluate it.  You are in fact suggesting that the code point assignment 
be denied until the IETF can find the time and be convinced that the 
protocol is "good".  In this case that does not make sense, because it 
does very little to keep the protocol from being deployed.  It will 
just get re-engineered to not need a code point. At that time the 
purists in the IETF will congratulate themselves for having fended off 
the dragon, while the Internet operators have to cope with a "stealth" 
version of the very protocol the purists tried to stop, instead of 
being able to filter on a known option number.

What if, in the case above, the code gets assigned along with 
publication of an RFC that in fact says that the code in question 
"belongs" to another organization and represents a non-IETF protocol 
that operators should filter unless they understand the implications of 
carrying these packets.  There could in fact be one such RFC that any 
code assignment of this type points to.  Now the Internet is actually 
safer, and there is an incentive for authors of protocols that were 
intended for wider use, because they will actually have to run the 
entire protocol through the IETF to get off the "black-list".  In fact 
I am suggesting (assuming no real code point shortage) that it is 
better to have a visible list of "assigned, but should not be generally 
used" codes than to assume that a non-assignment decision will keep the 
application off the Internet.

> developed outside the IETF exactly as to IETF documents.
Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer 
Science
292 Lindley Hall, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: John Leslie <[email-masked]>
Date: Wed, 13 Jul 2005 18:21:33 -0400

I generally support John Klensin's proposal. (Of course, the devil is
in the details...)

   I have not replied to previous messages, because I really didn't have
anything to add to the non-discussions there. But Hans raises some points:

Hans Kruse <[email-masked]> wrote:
> mean? 

   "Stewardship" should mean actual, effective, _use_ of a resource.

> The document(s) being revised/created should give some guidance to
> the community on how to use "percentage of space free" and/or "rate 

   I don't disagree; but we're not ready for that discussion.

> Then there is "Technical Review"; I actually agree that a level of
> such review is required, but is must be LIMITED (unless of course the 

   This is a genuine issue in the proposal by Dr. Roberts...

   But, IMHO, it's far better to _review_ that issue, and document the
negative impacts (which we have failed to do for the issue at hand).

> high school science projects).

   When the option space _is_ limited, John Klensin calls for
"initiation of a plan to eliminate the scarcity" before restricting
assignments to "those required to meet the needs of IETF protocol
development". I quite agree (though I'm prepared to allow for using
judgment short of the "restriction" John described).

   Hans is introducing a new idea: making a judgment about how likely
it is that "deployment will actually take place". This is an example
of judgment short of the "restriction" John described. I find it
reasonable, though I wouldn't rule out other "reasonable" judgment.

> I fundamentally disagree with "There's every reason that the same
> standard should apply to specifications developed outside the IETF
> exactly as to IETF documents" for the simple reason that it is 
> non-enforceable. 

   I also fundamentally disagree, but primarily because it asks for
omniscience, and our supply of potential IESG members is limited
enough without adding "demonstrated omniscience" to the requirements.

   Among the possible "plans to eliminate scarcity" might be to
assign a range of values for limited-time experimental use: keeping
in mind that our primary purpose in registration should be (as
John Klensin well stated) "Clarity of Definition". We want to have
a way of knowing what an option is being used for: the value of
knowing this easily outweighs the risk of experiments outlasting
their alloted time.

> Beyond stewardship of limited code point space, I see no
> justification for the IETF having veto power over standards being 
> independent developments are possible is at the heart of the
> success of the Internet.

   I agree with Hans here: a _large_ portion of the success of the
Internet has come from being able to develop new ideas without
waiting for the IETF _at_all_.

> protocol, and it should not feel the need to do so.

   Understand, the IETF _does_ have the right set of expertise to
review the _risks_...

   But I've seen no point in discussing here the intents and benefits
of Dr. Roberts' proposal: we may or may not have the expertise to
understand it all, but that expertise is not on _this_ list; and
there's insufficient justification for trying to gather it onto
any particular list.

   We _do_ need some work, being done somewhere, on the issues Dr.
Roberts' proposal seeks to explore. We should welcome that work,
wherever it might be done.

> It seems that you want a review of "is this protocol safe to deploy
> on the Internet"?  I can see the reasoning behind that, but I think
> the code point assignment review is the wrong place. 

   I partly agree with Hans here; but we're likely to get stuck
needing to review it at that point.

   What we do need (in that case) is to minimize the work of that
review, if it comes at an inconvenient time.

   The time-honored way to minimize the work of such a (mini) review
is to minimize the scope of what we claim to have reviewed. Thus,
if we limit ourselves to listing a few areas of concern, stating we
have not satisfied ourselves that these have been sufficiently
considered, we don't need to spend a lot of time explaining how
we reached that belief -- whereas if we state there _are_ problems
but decline to list them, we're opening ourselves to unending
discussions and unlimited research needs.

> ... purists in the IETF will congratulate themselves for having
> fended off the dragon, while the Internet operators have to cope
> with a "stealth" version of the very protocol the purists tried to
> stop, instead of being able to filter on a known option number.

   In the case at hand, Dr. Roberts wants to collect hop-by-hop
actually-available-bandwidth information in order to bypass the
slow-start mechanism of TCP. This _is_ scary!!!

   But the fact is, Dr. Roberts is working in an environment where,
with or without this hop-by-hop information, people _are_ going to
bypass slow-start. :^(

   So, if we dissuade Dr. Roberts from collecting the information
he wants, we're _very_ likely to end up in a worse state than if we
allow him to collect it. :^( :^(

   Thus, IMHO, we've got a clear case where assigning the code, in
combination with listing some concerns, is our best option.

   (That said, I do not mean to criticise the IESG for not seeing
the "superior wisdom" of my insight. ;^)

> "belongs" to another organization and represents a non-IETF
> protocol that operators should filter unless they understand the
> implications of carrying these packets...

   I recommend seriously considering such a possibility.

> Now the Internet is actually safer, and there is an incentive for
> authors of protocols that were intended for wider use, because
> they will actually have to run the entire protocol through the IETF
> to get off the "black-list".

   :^)

--
John Leslie <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 Jul 2005 01:12:59 -0400

--On Wednesday, July 13, 2005 16:57 +0200 Brian E Carpenter 
<[email-masked]> wrote:

> changes to

Brian,

Let me/us respond to the substantive part of your message 
separately.   However, I think the above is, if not equivalent 
to, at least vaguely similar to:  "forget everything that has 
been said about consensus documents, if the right people (maybe 
defined here as 'authors of original') post an I-D, it 
immediately supercedes the published document".   I think that 
makes me very anxious.

We have other rules that makes this problem even worse: when our 
I-D was written, one possibility was that it would gain some 
traction, it would be revised once or maybe twice, and we (or 
someone else) would request an IETF Last Call.   If that, in 
turn, went smoothly and quickly, we'd have a document that was 
intended to change the way registration procedures were 
conducted making a probably-normative reference to a working 
draft and the entire "update and fix to reflect community 
consensus" blocked both procedurally and on the flow of the RFC 
Editor queue.    Again, that doesn't seem like a good idea to me.

      john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jul 2005 10:22:30 +0200

John C Klensin wrote:
> Let me/us respond to the substantive part of your message separately.   
> However, I think the above is, if not equivalent to, at least vaguely 
> similar to:  "forget everything that has been said about consensus 
> documents, if the right people (maybe defined here as 'authors of 
> original') post an I-D, it immediately supercedes the published 
> document".   I think that makes me very anxious.

And I don't understand your interpretation.
2434 is a consensus document and 2434bis is in progress and, assuming
it makes it through the process, will emerge as a consensus document.
All I meant to say was: let's make sure that the pieces of
iana-reg-policy that would modify 2434 are discussed as part of
forming consensus about the contents of 2434bis. Otherwise, we'd
risk ending up with inconsistent output documents.

> 
> We have other rules that makes this problem even worse: when our I-D was 
> written, one possibility was that it would gain some traction, it would 
> be revised once or maybe twice, and we (or someone else) would request 
> an IETF Last Call.   If that, in turn, went smoothly and quickly, 

Why would it go more quickly than 2434bis, especially if the two
drafts remain inconsistent, as they certainly are right now?

> we'd 
> have a document that was intended to change the way registration 
> procedures were conducted making a probably-normative reference to a 
> working draft and the entire "update and fix to reflect community 
> consensus" blocked both procedurally and on the flow of the RFC Editor 
> queue.    Again, that doesn't seem like a good idea to me.

It wouldn't be a good idea. I would want to last call 2434bis and
iana-reg-policy simultaneously, with a specific intent that
they be mutually consistent.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jul 2005 10:42:25 +0200

(reminder - my AD hat is off for this part of the discussion)

John Leslie wrote:
...
> Hans Kruse <[email-masked]> wrote:
...
> negative impacts

I agree. Did I write something that indicated otherwise?

> (which we have failed to do for the issue at hand).

Correct, so far. And despite the IESG's recommendation, I expect that
we (the IETF) will get the chance to do so in the case in point.

...
> enough without adding "demonstrated omniscience" to the requirements.

It is enforcable and doesn't call for omniscience. When an outside
body or person asks for one of these assignments, they are asked to
provide a justification or specification. That's what the IETF
will review.

...
> waiting for the IETF _at_all_.

Yes. What we're arguing about is whether there some specific domains
in which the stability of the Internet is at risk, and whether
parameter assignments in those domains can be treated neutrally.

...
> needing to review it at that point.

In fact, if a spec is developed elsewhere, as in this case, the fact
is that the assignment review is the *only* place available for
IETF review. That, I think, is why RFC 2780 was written

...
>    I recommend seriously considering such a possibility.

I agree that this would be very reasonable. It's very analogous to the
Experimental/Local Use diffserv code points.

See draft-fenner-iana-exp-2780-00.txt.

     Brian

---

From: David Hopwood <[email-masked]>
Date: Thu, 14 Jul 2005 15:54:27 +0100

> nicely through the registered port numbers.

I was surprised that TCP-over-IPv6 and UDP-over-IPv6 didn't increase
the port number space. I know it's off-topic here, but anyone know why
they didn't? It surely must have been considered.

-- 
David Hopwood <[email-masked]>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 14 Jul 2005 11:13:26 -0400

>they didn't? It surely must have been considered.

That was considered to be part of TCPng, and as best I recall was 
explicitly out of scope.

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

---

From: [email-masked] (Scott Bradner)
Date: Thu, 14 Jul 2005 12:15:26 -0400 (EDT)

> That was considered to be part of TCPng, and as best I recall was 

correct

Scott

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Jul 2005 18:32:37 +0200

> deployment effort involved in expanding it has prevented any action.

Well, how is deployment going to happen if the specification never  
progresses beyond being a draft in half a decade?

Also, draft-ietf-idr-as4bytes-10.txt has excellent backward  
compatibility so deployment shouldn't be much of a problem if we take  
enough time.

However, for some inexplicable reason a sizable number of operators  
are violently set against increasing the AS number space.

> This month's poster

It would be a very bad idea to increase the port number space. The  
reason a port number must be in every packet is in order to  
demultiplex different sessions between a pair of hosts. For this, 2 x  
16 bits is more than enough. Port numbers are also used to identify  
the application protocol in question, but this only needs to happen  
when a session or association is established.

So when the port numbers run out, let them eat SRV records.

(And architecturally, port numbers in different places in different  
transport protocols are an abomination. They should be part of the  
address.)

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 14 Jul 2005 18:36:24 +0200

> they didn't? It surely must have been considered.

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.

Greets,
 Jeroen

* = Listening sockets of course limit this quite a bit, but even with
20000 listening sockets, 40k*60k is still a lot.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 14 Jul 2005 18:38:57 +0200

At 17:23 14/07/2005, Brian E Carpenter wrote:
>Since we don't have a WG for this, the IETF list is the only place
>right now.
>Brian

I would recommand a WG. This would permit to have a merge of the current 
propositions, to engage into more complex issues such as:

- compatibility with externally defined elements (ex. ISO 3166 discussed in 
RFC 1591)
- political disclaimer when a registry may be construed as a support for a 
political, commercial or technical vision.
- experimentation
- registry system architecture and generic registry solution
- multilingual support in spite of the current state of the art technology 
limitations
- harmonisation with ISO 11179, inter-registry relations
- transition from namespace towards ASCII non dependent codespaces
- distributed registries, relations with private or experimental/temporary 
registries, registries specialised restrictions
- reporting on registries updates and corrections
- registry managers committees selections
- updates via Working Group RFCs
etc.

jfc

---

From: David Hopwood <[email-masked]>
Date: Fri, 15 Jul 2005 01:20:53 +0100

>>That was considered to be part of TCPng, and as best I recall was 

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.

Jeroen Massar wrote:
> enough(tm) ;)

Not for connections to a well-known port.

---

From: Ned Freed <[email-masked]>
Date: Thu, 14 Jul 2005 18:25:28 -0700 (PDT)

> 65536 connections at the same time.

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

I can assure you that this is a problem for real-world applications in some
cases, so yes, there are such users.

				Ned

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Jul 2005 09:55:24 +0200

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

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.

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2005 11:02:50 -0400

>     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

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Jul 2005 09:11:32 -0700 (PDT)

> Sounds like an implementation limitation to me.

Reread my message. It is nothing of the sort.

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Jul 2005 19:06:28 +0200

> design limit and not an implementation limit.

Sure.

> And you'd be wrong.

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

> The specific case I've seen is with IMAP4. IMAP4 has the

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.

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

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.

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Jul 2005 09:58:29 -0700 (PDT)

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

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

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Jul 2005 10:14:23 -0700 (PDT)

> 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

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

> actual server port, making all the sessions seem to come from the

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

---

From: Bob Hinden <[email-masked]>
Date: Fri, 15 Jul 2005 10:31:19 -0700

David,

>    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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 15 Jul 2005 19:32:25 +0200

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jul 2005 19:36:57 +0200

> 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
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2005 13:40:13 -0400

--On Friday, 15 July, 2005 10:31 -0700 Bob Hinden
<[email-masked]> 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

---

From: John Day <[email-masked]>
Date: Fri, 15 Jul 2005 13:54:20 -0400

>(those are questions, not proposals, requests, or statements of

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

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Jul 2005 11:10:57 -0700 (PDT)

> when you don't have to upgrade the entire internet to solve the

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Jul 2005 14:35:10 -0400

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

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Jul 2005 09:34:11 -0700

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

		Mike

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Jul 2005 16:47:07 -0700 (PDT)

> 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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Jul 2005 21:02:16 -0500

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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 15 Jul 2005 22:16:09 -0400

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