On 13-jul-2005, at 16:57, Brian E Carpenter wrote:
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.
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
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.
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.)
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf