Karl Denninger <karl@Mcs.Net> writes:
IPng needs to have enough *prefix* length that every autonomous system currently in existance or which will come into existance during its lifetime can have a *unique*, *single* prefix.
This has the advantage of maximizing site aggregation, however it has the disadvantage of scaling badly with respect to the number of sites.
Then the whole address ownership issue becomes moot - each ASN becomes a prefix (heh, now that's novel - why not just use the ASN - duh!)
Sure, but the problem is not now who deserves a /19 but who deserves an ASN. Moreover, there is no plan in place for a hierarchical distribution of AS numbers, and ASes are not laid out very hierarchically (or in any kind of useful order) right now. If a very strict limit were placed on the number of ASes in this type of Internet, then distributing connectivity maps likely would be tractable; this leads into discussions about a global link-state routing protocol, some of which happen from time to time for other reasons. However, if you are not prepared to refuse to give out AS numbers to anyone who wants one, you will run into the same political problems as refusing to give out provider-independent addresses to anyone who wants some. Alternatively, if you provide a mechanism for aggregation of ASes (and don't go mad in the process), thus implying hierarchical routing, then your idea is workable, except that suddenly there is no difference between the semantics of your ASN+IPADDR and the IPv6 provider-based addressing scheme. The big difference would be in the requirement that only a fixed-size field be routed upon, which is very much like imposing prefix-length filtering on IPv6 addresses. The only known means for any IP-like protocol to scale to complex topologies is hierarchical routing. This imposes constraints on address assignment. There is no way around these constraints other than abandoning topological complexity or routing efficiency. I believe that the functionality you are trying to achieve is having a system in which renumbering is unnecessary when a change is made in the physical topology, or where address uniqueness is not guaranteed. NAT is currently the appropriate technology to be used in both cases, and has the advantage that no NAT-friendly deployed software needs to be changed to talk a new protocol.
This kind of logical design, of course, cannot be allowed to happen within the realm of the Internet, which is why we'll never see it in our lifetime.
Why not? NATs delineate two addressing scopes, and protocol translating NATs are an extension of this. Pablo Bevilacqua has already pointed out an existing implementation from OFRV. There is no reason why a series of NATs which each border on different IPv4 addressing scopes cannot share a common protocol and addressing region on the "outside" of each of these IPv4 addressing scopes. That is, among a group of NATs there is no strict need to run IPv4, so long as straightforward translations into and out of the local IPv4 addressing scopes are possible. Consequently, there is no reason why some part of the Internet cannot test or even deploy your hypothetical protocol. Personally I encourage you to go for it; there is alot we need to learn about what ought to be "in the middle" to keep the Internet permanently scalable, and the concept of protocol translating NATs needs some thorough deployment experience. Sean.
On Fri, Nov 07, 1997 at 09:01:18AM -0500, Sean M. Doran wrote:
Karl Denninger <karl@Mcs.Net> writes:
IPng needs to have enough *prefix* length that every autonomous system currently in existance or which will come into existance during its lifetime can have a *unique*, *single* prefix.
This has the advantage of maximizing site aggregation, however it has the disadvantage of scaling badly with respect to the number of sites.
Not if you define "site" as "one network owned by an entity or related set of entities". Of course, then what happens is that you have to revoke the multiple ASNs that some providers have - which IMHO should NOT have been issued. "Administrative convenience" isn't a valid reason to be issuing ASNs all over the place. There is no *need* to do so - there may be a *want* to do so, primarily because people don't want to carry their own customer's traffic for the majority of the trip in even one direction (which IMHO is baloney, but heh, that's just my point of view).
Then the whole address ownership issue becomes moot - each ASN becomes a prefix (heh, now that's novel - why not just use the ASN - duh!)
Sure, but the problem is not now who deserves a /19 but who deserves an ASN.
Anyone who connects to and exchanges routes with two or more other ASN holders. If you're part of the mesh, then you need an identification number to *BE* part of the mesh.
Moreover, there is no plan in place for a hierarchical distribution of AS numbers, and ASes are not laid out very hierarchically (or in any kind of useful order) right now.
Not very relavent, really. Think about it - right now BGP4 uses the path length as the first-order determinant. If you had one route entry for each ASN, and only one, then By Golly, we'd have something like 5,000 prefixes in the table right now. Heh, anyone like the idea of being able to run on AGS+ platforms again and other things with limited RAM and CPU power? Sure would be nice, wouldn't it?
maps likely would be tractable; this leads into discussions about a global link-state routing protocol, some of which happen from time to time for other reasons.
Yep.
However, if you are not prepared to refuse to give out AS numbers to anyone who wants one, you will run into the same political problems as refusing to give out provider-independent addresses to anyone who wants some.
Well, no. You give out AS numbers to anyone who is a member of the mesh. By *definition* to be a mesh member you must exchange information with more than one other party. If you do, then you're a mesh member. If you do not, then you are not.
Alternatively, if you provide a mechanism for aggregation of ASes (and don't go mad in the process), thus implying hierarchical routing, then your idea is workable, except that suddenly there is no difference between the semantics of your ASN+IPADDR and the IPv6 provider-based addressing scheme.
Aggregation of ASNs is interesting, but I believe both unnecessary and politically dangerous (for the same reason that I believe that aggregation of IPv4 addresses now can be dangerous in that it can be used to restrain trade).
The big difference would be in the requirement that only a fixed-size field be routed upon, which is very much like imposing prefix-length filtering on IPv6 addresses.
Yep. In fact it is *exactly* that; the fact that the high order bits are defined as the ASN is an administrative convenience.
The only known means for any IP-like protocol to scale to complex topologies is hierarchical routing.
One multiply-connected entity, one hierarchy. The requirement of multiple connections is a natural limit to an explosion of hierarchies. Also, with address space being effectively unlimited, there is no longer a reason for people to persue this for any reason other than route exchange - it buys you NOTHING. See my other posting regarding low-order-bit confederation agreements to allow full portability at the *customer* level without people needing to have their own ASN. This instantly removes the argument for and desire to obtain ASNs for what some people now call "vanity" purposes (and what I call a survival requirement).
This imposes constraints on address assignment. There is no way around these constraints other than abandoning topological complexity or routing efficiency.
The point is that constraints on an unlimited resource which *STILL* looks unlimited after the constraint is applied are null operations as far as the external impact goes. This is why the split that I've described works and doesn't really inconvenience (or screw) anyone.
I believe that the functionality you are trying to achieve is having a system in which renumbering is unnecessary when a change is made in the physical topology, or where address uniqueness is not guaranteed.
Correct. I am trying to achieve a level playing field.
NAT is currently the appropriate technology to be used in both cases, and has the advantage that no NAT-friendly deployed software needs to be changed to talk a new protocol.
NAT is *not* currently the appropriate technology because people have designed brain-dead protocols which encode endpoint addresses INSIDE THE PAYLOAD REGION of datagrams. This requires all kinds of special-casing. That the IETF has *approved* such protocols, and continues to do so, is a huge problem. In fact it is THE problem which makes NAT unworkable in the general sense. Unfortunately, one of those protocols is one of the earliest - FTP. But its not the only abuser by any stretch of the imagination.
There is no reason why a series of NATs which each border on different IPv4 addressing scopes cannot share a common protocol and addressing region on the "outside" of each of these IPv4 addressing scopes. That is, among a group of NATs there is no strict need to run IPv4, so long as straightforward translations into and out of the local IPv4 addressing scopes are possible. Consequently, there is no reason why some part of the Internet cannot test or even deploy your hypothetical protocol.
Personally I encourage you to go for it; there is alot we need to learn about what ought to be "in the middle" to keep the Internet permanently scalable, and the concept of protocol translating NATs needs some thorough deployment experience.
Sean.
We need to fix the broken protocol problem too Sean... Fix that and translation at boundaries becomes VERY workable. In fact, if we fix that I will agree that such a reference implementation is worth my effort and will see what I can code up for precisely this purpose. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
On Fri, 7 Nov 1997, Karl Denninger wrote:
Of course, then what happens is that you have to revoke the multiple ASNs that some providers have - which IMHO should NOT have been issued.
"Administrative convenience" isn't a valid reason to be issuing ASNs all over the place. There is no *need* to do so - there may be a *want* to do so, primarily because people don't want to carry their own customer's traffic for the majority of the trip in even one direction (which IMHO is baloney, but heh, that's just my point of view).
The legitimate reason for multiple ASs is when separate parts of the network have very different routing. For example, let's say a big company on a single continent has one prefix for their whole network. They then expand to another continent. If they use address space under that same prefix, they wind up either having the transcontinental link large enough to support all of the transcontinental traffic for that prefix, or they wind up routing traffic across a transcontinental link and back when it didn't have to. Now, if they get a different prefix for the new continent, traffic will take the optimal path. This is no different than inefficiencies caused by the current implementation. Generally, traffic gets to the destination AS as quickly as possible and then finds its way to the destination host from there. However, there may be a shorter path involving a different entry point into the destination AS. With the larger address space of IPv6, there is the capacity for an arbitrary number of levels in the hierarchy. Obviously, making use of those levels to improve on the inefficiency noted above will require more routes to be propagated, so there is a tradeoff. I don't think we want either a routing table contaning one route per AS nor do we want one containing every subnet with each AS. Ideally, we would choose some level of detail between those extremes, using multiple routes per AS only where they actually improve routing. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Fri, Nov 07, 1997 at 09:51:30AM -0600, John A. Tamplin wrote:
On Fri, 7 Nov 1997, Karl Denninger wrote:
Of course, then what happens is that you have to revoke the multiple ASNs that some providers have - which IMHO should NOT have been issued.
"Administrative convenience" isn't a valid reason to be issuing ASNs all over the place. There is no *need* to do so - there may be a *want* to do so, primarily because people don't want to carry their own customer's traffic for the majority of the trip in even one direction (which IMHO is baloney, but heh, that's just my point of view).
The legitimate reason for multiple ASs is when separate parts of the network have very different routing. For example, let's say a big company on a single continent has one prefix for their whole network. They then expand to another continent. If they use address space under that same prefix, they wind up either having the transcontinental link large enough to support all of the transcontinental traffic for that prefix, or they wind up routing traffic across a transcontinental link and back when it didn't have to. Now, if they get a different prefix for the new continent, traffic will take the optimal path.
This is no different than inefficiencies caused by the current implementation. Generally, traffic gets to the destination AS as quickly as possible and then finds its way to the destination host from there. However, there may be a shorter path involving a different entry point into the destination AS.
With the larger address space of IPv6, there is the capacity for an arbitrary number of levels in the hierarchy. Obviously, making use of those levels to improve on the inefficiency noted above will require more routes to be propagated, so there is a tradeoff. I don't think we want either a routing table contaning one route per AS nor do we want one containing every subnet with each AS. Ideally, we would choose some level of detail between those extremes, using multiple routes per AS only where they actually improve routing.
John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
This I agree with. We could, for example, define a "country code" set of bits in the high-order field of the "provider" area. For example, from the LEFT side of the IPv6 address (128 bits wide): Bits 0 - 8 - Reserved for when interplanetary travel and subspace communication become functional (to define "Galaxies" - this appeases Jim Fleming and Star Trek types :-) :-) 9 - 17 - Country code (1024 countries; there's only so much land on the planet, and we're well under that now I believe :-) 18 - 47 - Reserved for future use 48 - 63 - Provider's AS Number ======================== Boundary of externally-visible address space from a provider (ie: you route to a /64 level) Everything below this point "belongs" to the provider. 64 - 95 - Reserved for internal assignment once IPv4 direct backward mapping is no longer relavent (or desired). 96 - 127 - Existing IPv4 mapping, 32 bits, provider dependant and internal. Now, think what this does: 1) Any address for a level beyond where you are only needs to seek the closest exit point (ie: if you're in "galaxy" 0, and you get a packet for "galaxy 1", you don't need to look at or care about the rest - find the closest "galaxy 1 exit". 2) Routing at the *country interconnect level* only requires a lookup of 1024 possible destinations - easily done with a direct index table (which is a *ONE INSTRUCTION* decision in core routers). Multinational providers use bits 9 - 63 to make routing decisions while single-nation providers only use bits 48-63 and have a 1024-entry "forward to the best exit table" for bits 9-17. This also permits implementation of TOS and QOS restrictions based on destination or source country, which is something we're going to have to face sooner or later. 3) Routing between ASNs is a 16-bit issue (ie: 65,536 ASNs within a country, which is the MAXIMUM number of entities in one country - and if this isn't enough, encroach on the "reserved" areas). The initialization sequence for the Son-of-BGP4 communicates the size of this field so that as it grows its seamless to implement. 4) IPv4 space maps *directly* onto this at a low level, preserving the option of FULL backward compatibility. 5) Once we don't *CARE* about backward IPv4 mapping every doorbell, toaster, car, and wristwatch within a PROVIDER can be accomodated in 64 bits! This solves all of the allocation problems, GREATLY simplifies routing to the point that a $2,000 router now can effectively be a multi-homed device (since the "thinking" part just got incredibly simple) and makes convergence a non-issue. A gateway device to map between this layout as a backbone level transport and existing IPv4 is trivial. Confederations of providers can decide to cooperate on the bit 96 - 127 address range; if they DO cooperate then you have inter-provider portability. If not, then you still *might* have it, depending on whether the numbers you were using have been assigned to someone else on the new provider you're moving to or not. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
Yo Karl! On Fri, 7 Nov 1997, Karl Denninger wrote:
We could, for example, define a "country code" set of bits in the high-order field of the "provider" area. For example, from the LEFT side of the IPv6 address (128 bits wide):
Bits 0 - 8 - Reserved for when interplanetary travel and subspace communication become functional (to define "Galaxies" - this appeases Jim Fleming and Star Trek types :-) :-)
9 - 17 - Country code (1024 countries; there's only so much land on the planet, and we're well under that now I believe :-)
48 - 63 - Provider's AS Number
How would you handle large providers that accept local traffic using the same AS in numerous countries? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 2680 Bayshore Pkwy, #202 Mountain View, CA 94043-1009 gem@rellim.com Tel:+1(650)964-1186 Fax:+1(650)964-1176
Karl Denninger wrote:
We could, for example, define a "country code" set of bits in the high-order field of the "provider" area. For example, from the LEFT side of the IPv6 address (128 bits wide):
Have little experience in international networking, ain't we? Take Russian Internet for example: five largest ISPs all have separate dedicated links to _different_ European and North American backbones. This seems to be a typical picture all around the world. European connectivity is particularly convoluted. --vadim
Take Russian Internet for example: five largest ISPs all have separate dedicated links to _different_ European and North American backbones.
This seems to be a typical picture all around the world. European connectivity is particularly convoluted.
For years, Thailand had for separate competing connections to AlterNet. I loved it, as it demonstrated a minimum market price of ego. Of course, there are no analogs to this in North American locales. Right. randy
This illustrates my earlier comments about why geographically-based allocation schemes are not ideal. - paul At 02:46 PM 11/7/97 -0800, Vadim Antonov wrote:
Take Russian Internet for example: five largest ISPs all have separate dedicated links to _different_ European and North American backbones.
This seems to be a typical picture all around the world. European connectivity is particularly convoluted.
Have little experience in international networking, ain't we? well it is sometime better to have a big pipe to the US than a two smaller pipes to Europe and US :-)
Take Russian Internet for example: five largest ISPs all have separate dedicated links to _different_ European and North American backbones.
well just wait a few weeks, than - if nothing happens - about 20 Mbit/sec of Traffic now exchanged within germany will go over us. Not because of a technical problems but due to political problems. This concers nearly all traffic between the german commercial ISPs and the academic part of the germany internet (DFN/WIN). All majer isps have cancelled their contract with the dfn for 31/12/97 because the commercial isps are no longer willing to pay for access to the academic networks. The traffic is going in both directions, but it cant be right, that only one site pays. And only one AS (and customer ASes) are accepted, but no AS from another ISP. This costs additional $$ BTW: a E1 contact with DFN costs about 6000$ a month + local loop to their next access point!.
This seems to be a typical picture all around the world. European connectivity is particularly convoluted.
yes, thats how the wourld comes together Cheers Winfried Winfried Haug | SEICOM.DE & SCHWABEN.DE | Tel. 07121 9770- 0 Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. 07121 9770-19 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack 07127 989-X haug@schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack 0711 9675-X haug@seicom.net |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack 07121 709-X * 4 MBit DE-CIX * 2 MBit WIN * 2 MBit BelWue * 2 MBit INXS * 2 MBit UU.NET *
participants (8)
-
Gary E. Miller -
John A. Tamplin -
Karl Denninger -
Paul Ferguson -
Randy Bush -
Sean M. Doran -
Vadim Antonov -
Winfried Haug