RE: Using BGP to force inbound and outbound routing through particular routes

Mailman List Mirror (Read Only)
41

> Is AS reclaimation an option? We don't know how many 'dark'
> (unadvertised) AS numbers are used as VPN IDs in 2547 contexts.

do we care? i.e. does it affect the real public internet. are
these not like 1918?

nope, they need to be unique... or they SHOULD BE unique (globally
unique). As more folks interconnect internally (business mergers,
partnerships, things such as this) there will be more clashes on 1918
(raising the evil spectre that is NOT the AC-130, but in fact NAT) and ASN
clashes resulting in fragile internal networks needing an ASN swap-out...
which is devilishly hard so I've heard. (atleast on a large network)

> Current figures indicate that it would work for 3 years if we
> were able to reclaim ALL unadvertised AS numbers and recycle
> them. How much effort would it take to get this additional 3
> years?

and how much money will lawers make off the ensuing riot?

lawYers will always make money... but I'm not sure that 'unadvertised' is
the metric you want to use here. 'unpaid' might be better.

42

Is AS reclaimation an option? We don't know how many 'dark'
(unadvertised) AS numbers are used as VPN IDs in 2547 contexts.

do we care? i.e. does it affect the real public internet. are
these not like 1918?

nope, they need to be unique... or they SHOULD BE unique (globally
unique). As more folks interconnect internally (business mergers,
partnerships, things such as this) there will be more clashes on 1918
(raising the evil spectre that is NOT the AC-130, but in fact NAT) and ASN
clashes resulting in fragile internal networks needing an ASN swap-out...
which is devilishly hard so I've heard. (atleast on a large network)

we either believe in private ip/asn space or we don't. if we do,
then this asn usage falls under it.

and how much money will lawers make off the ensuing riot?

lawYers will always make money.

sorry. typing while dealing with remote server messes.

but I'm not sure that 'unadvertised' is the metric you want to
use here. 'unpaid' might be better.

please see what we promised fnc when we formed arin, slide nine of
<http://rip.psg.com/~randy/970414.fncac.pdf&gt;\. i think this is
perceived as the social contract with the legacy community. and
some old legacy dogs are pretty adamant about this, hi jis.

and we have both a simple and a more complex compatible transition
path to four byte asns. it's ip addresses where we have no
compatible transition path. eye on doughnut and all that.

randy

43

> RIRs, and if we assume no change in AS number policies, and no
> change in the trend of ageing out 'old' AS numbers at a rate of
> some 5% per year into the unadvertised pool, then the 2byte field
> will exhaust sometime in October 2010.

no waffling. you said october 14th, and we're holding you to it!
we would like to know about what time of day, so we can schedule
lunch and coffee.

well, the figures indicate that RIPE will receive 10 requests on that day, and will start the day with 5 left in their pool. So the first allocation processed after lunch will fail - so that would mean at 2:00 pm CET on the 14th October 2010 - or thereabouts! :-).

> Is AS reclaimation an option? We don't know how many 'dark'
> (unadvertised) AS numbers are used as VPN IDs in 2547 contexts.

do we care? i.e. does it affect the real public internet. are
these not like 1918?

practice and theory. In theory whether such as's are used in private contexts or not makes no difference as to their potential to be used in the public Internet. The practice this may not be so easy.

> Current figures indicate that it would work for 3 years if we
> were able to reclaim ALL unadvertised AS numbers and recycle
> them. How much effort would it take to get this additional 3
> years?

and how much money will lawers make off the ensuing riot?

Certainly a factor that can't be ignored completely!

Which is why I've offerred the perspective that it may be easier to simply
press on with the 4-Byte AS work and get the routers into a position to be able
to accept the deployment of 4-Byte ASs, rather than debate at some length
the potential cost and benefit of forms of reclaimation efforts in this space.

regards,

    Geoff

44

no waffling. you said october 14th, and we're holding you to it!
we would like to know about what time of day, so we can schedule
lunch and coffee.

well, the figures indicate that RIPE will receive 10 requests on that day,
and will start the day with 5 left in their pool. So the first allocation
processed after lunch will fail - so that would mean at 2:00 pm CET on the
14th October 2010 - or thereabouts! :-).

                         v
uh, won't that be 14:00 CST? as we don't do summertime here,
this difference will impact my first cuppa.

Is AS reclaimation an option? We don't know how many 'dark'
(unadvertised) AS numbers are used as VPN IDs in 2547 contexts.

do we care? i.e. does it affect the real public internet. are
these not like 1918?

practice and theory. In theory whether such as's are used in
private contexts or not makes no difference as to their potential
to be used in the public Internet. The practice this may not be
so easy.

we believe in private space or we don't. if we do, then they can
use private asns or snatch public ones and keep their 42 ribs
from mixing. if we don't, then we have to stop whining about
giving folk real unique ip address space and asns we never see on
the public net.

Which is why I've offerred the perspective that it may be easier
to simply press on with the 4-Byte AS work and get the routers
into a position to be able to accept the deployment of 4-Byte
ASs, rather than debate at some length the potential cost and
benefit of forms of reclaimation efforts in this space.

we're in agreement here, though, as you know, i am more inclined
to the "you have five years to upgrade" conversion approach. less
exposure to router code and config bugs.

but ip space is a much harder issue. v6 did not come with a
transition plan and still has no credible one.

randy

45

my mistake - yes, that will be CST rather than CET

I trust that this adjustment will not impact your scheduling of the lunch and coffee caterers :slight_smile:

As you point out, the IP issue is much harder, and because the transition is so markedly different from the AS one the dynamics of exhaustion of the unallocated IP V4 address pool will undoubtedly be different (and much harder to use relatively simple numerical methods to predict). I could use the word "panic" but as we are all responsible and careful players here let's just call it the looming scenario of folk looking at "last chance direct IPv4 address allocations" in the near term future. I'd be interested if anyone here has some generic modelling tools that include modelling of such so-called 'panic' situations, as I'd be interested to apply it to this situation in various ways.

   Geoff

46

Well to be fair, classful routing actually did have a few advantages.
Longest prefix match lookups have historically always been very difficult,
so difficult that it held back the speed of routers for years. We've only
recently been able to get a handle on the problem in hardware.

Also, some of the original motivations behind CIDR starts to go out the
window when you have enough IP space that you can hand out huge chunks
ahead of immediate need. Who cares about efficient utilization or "but I
only need a /35 and you gave me a whole /32, I'm wasting so much space"
when there is not a space shortage. Just allocate enough space that you
will never need to upgrade, you'll be doing more good than trying to
predict or restrict your usage and creating more routing entries later
when you need more space.

Of course none of this is a compelling argument for classful routing.
We've pretty much got the longest prefix match thing covered at this
point, and claims that we need to scale bgp to support 2^128 routes so
that everyone can multihome their refrigerators are a load of crap. Also,
just because 2^128 is a big number does not mean that all IPv6 space is
infinite, and there is no reason to get short-sighted. If we're really
going to end up in a situation where a /64 is a "host", then a /48 is the
equivilent of a /16 on IPv4. That is a decent sized chunk for "small"
users, but hardly infinite. If you are a larger provider with a /32 and
you have to hand out /48s to everyone, it is like only having a /16
yourself. Imagine a large cable company who had to give an IP to every
customer and trying to get it all done in a single /16. Suddenly all this
massive space seems to be running low. /56s and the like as allocations
seem like a really bad and short-sighted idea, unless we're talking about
it for nothing more than "business-class end-user service" like a /27 on a
business grade DSL circuit today.

I'm still not seeing any reason that everything can't work itself out
through existing means. Make the preferred allocation size from RIRs /32,
to be given out to large networks or anyone with an ASN who asks for one.
Make the preferred reallocation size for enterprises /48, and make it the
smallest block which can be announced in BGP (with the expectation that
/32s will be the primary announcement). Make the preferred assignment for
end-users (cable modems and such) /64, and use the remaining 64 bits as a
giant waste of time but one that makes certain we won't have to deal with
NAT ever again.

47

Also, some of the original motivations behind CIDR starts to go out the
window when you have enough IP space that you can hand out huge chunks
ahead of immediate need. Who cares about efficient utilization or "but I
only need a /35 and you gave me a whole /32, I'm wasting so much space"
when there is not a space shortage. Just allocate enough space that you
will never need to upgrade, you'll be doing more good than trying to
predict or restrict your usage and creating more routing entries later
when you need more space.

The original motivation behind this conversation stems from some long held concerns that the address plan for IPv6 may not encompass our visions of a network that serves a device dense world for many decades to come.

ISP Column - July 2005 contains one description of this concern.

At issue here is two somewhat different views of the deployment scenarios of the network.

One view is to attempt to use the larger address space to make deployment incredibly simple, and eliminate some of the overhead we have in IPv4 in our efforts to make the IPv4 address space last. So the IPv6 address plan says /48's to end sites with no assessment of end-site address utilization. The IPv6 address policy says use an HD Ratio of 0.8 to assess the requirement for additional address allocations. The IPv6 address policy says use a minimum initial allocation of a /32.

In looking at these parameters, and making some pretty rough calculations of what a device-dense world would look like then it would appear that this plan would work for an end site population of between 50 to 200 billion, which would fit within this address plan - not comfortably, but it would fit.

What if we have underestimated this population?

In this view, the resolution is best expressed in RFC3177: "Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies"

The other view is that by then the installed base will be so large (up to tens of billions of end sites) that any form of adjustment of the IPv6 address space will be extremely difficult, if not impossible. Within this view, the motivation is to set up an address plan that encompasses a margin for error in our assessments of future IPv6 network address requirements, while attempting to preserve as much of the essential elements of simplicity in the address plan as possible.

To this end policy proposals to adjust the HD ratio to 0.94 have been proposed in APNIC, ARIN and RIPE this year, and the reaction from the addressing communities to this proposal have been largely positive. But there is still the lingering doubt (at least personally) that we really don't know how big and for how long we need to rely on IPv6, and the 3 bits (factor of 1 order of magnitude) you are likely to get from this HD ratio may not be enough. From this doubt came the second part of the proposal to define a second end site allocation point, namely that of a /56. This part of the proposal was not well received by any of these three policy fora.

The reaction that this /56 end site allocation point has received has been twofold ; one that it impacts the existing deployed base of IPv6, and secondly, and perhaps more fundamentally, its not the RIR's role to define what an end-site allocation may be within any particular ISP, and this definition of /48, /56 and /64 looks very reminiscent of the old Class-full address plan of IPv4 over a decade ago. So it appears that this approach of simply defining another end-site allocation point does not have broad acceptance, and there is a clear message to go back and think some more about what is the issue here and how best to address it.

The real issue here is NOT the definition of allocation points per se. The address plan used by an ISP ultimately falls within the business scope of the ISP itself. The central issue, if you accept that premise that end-site allocations are up to the ISPs, is how to define the algorithm to be used by the RIR to assess whether an existing allocation has been "fully utilized" in terms of end-site address allocations. So what algorithm could be used to assess address utilization in a manner that would provide _reasonable_ incentives to use the address space in a manner that preserves IPv6's future utility across many decades to come (and encompasses a pretty large margin for error in our very imperfect views of the future)?

For me that's at the heart of this discussion, and of course I'd be very interested to hear what ideas others may have on this topic.

regards,

     Geoff

48

As of a few minutes ago there are 21.042 unique ASs seen in Route-Views.

13,997 are origin onlu (i.e. they are not seen in the middle of an AS path), 66 are transit only and 6.979 are mixes origin + transit.

8,554 ASs announce a single prefix, while the average announcements per origin AS is 9.1 (the reason is a heavy tail distribution where a small number of ASs originate a very large number of prefixes)

The average address span for an origin AS is 70,426 /32s (or slightly larger than a /16) Again this is a heavy tail distribution.

(more time series data on the routing table than you'd ever want is at http://bgp.potaroo.net/as4637/ and http://bgp.potaroo.net/as6447)

The overall trend is the association of fewer addresses per originating AS, pointing to a trend to impose ever finer levels of policy delineation within the inter-domain routing mesh at places closer to the edge of the network - i.e. multi-homing and traffic engineering within an increasingly dense interconnection mesh appear to be one of the major motivations here for the continued consumption of AS numbers. The CAIDA skitter graphs are perhaps the most dramatic way I've encountered so far that clearly shows this trend.

regards

    Geoff

49

Hello;

>
> - -- BGP is currently moving to a 2^32 space for AS numbers. That's odd,
> if there's only 18,044 origins in the current table, and it won't ever
> grow to much more--how'd we lose 40,000 or so AS numbers, that we now
> need more than 64,000?

I think someone at CAIDA or even Renesys could put out some good numbers
for 'origin' AS counts and even 'AS in aspath' It's slightly higher than
18k, but not 40k higher :slight_smile: At last look (during arin/nanog meeting) it was
about 20k unique origins (from 701 perspective as seen through
routeviews)

As of a few minutes ago there are 21.042 unique ASs seen in Route-Views.

From the multicast status page, http://www.multicasttech.com/status/

I get a total number of Active Unicast AS seen by BGP = 20660 (a little smaller than Route-Views), and a total
of 22038 having _ever_ been seen by BGP announcements here (since April, 2001).

There are clearly more AS's in use out there in non-public networks, as seen, e.g., by the steady
dribble of low number DOD ASN's that leak out from time to time, but it does
not seem that this pool is very large.

Regards
Marshall Eubanks

50

What about those that are assigned and used but not [currently] visible
on the public Internet [i.e., are on other internets]?

Indeed!

On Henk's slide number 5 he states:

"Each AS wants to be able to send traffic to any other AS"

This is NOT true. Many ASes explicitly do *NOT*
want to send traffic to any other AS. They only want
to send traffic to customers, vendors or business
partners of some sort. In other words, there are many
so-called extranets which are basically internets
built using exactly the same technology as the Internet
however with more restrictive interconnect policies.

One way to visualize this is to imagine the Internet
as a cloud. At the core of the cloud are the core
providers and at the edge of the cloud are the end
user organizations, many of which appear to be
singly homed. However, hidden behind this edge is
a thin layer which represents a private internet.
It also connects many networks but it does *NOT*
exchange traffic with the public Internet. All the
networks connected to these private internets are
also connected to the public Internet but they
implement strict traffic separation policies
internally. In some cases, this is an air gap but
these days it is often a bunch of firewalls.

In the 24/7 connected world of the 21st century
there is a lot of growth in these internets that
wrap around the Internet but don't exchange vital
fluids with it.

--Michael Dillon

51

Wanting to do something and wanting to be able to do something are different.

52

Thus spake <Michael.Dillon@btradianz.com>

One way to visualize this is to imagine the Internet
as a cloud. At the core of the cloud are the core
providers and at the edge of the cloud are the end
user organizations, many of which appear to be
singly homed. However, hidden behind this edge is
a thin layer which represents a private internet.
It also connects many networks but it does *NOT*
exchange traffic with the public Internet. All the
networks connected to these private internets are
also connected to the public Internet but they
implement strict traffic separation policies
internally. In some cases, this is an air gap but
these days it is often a bunch of firewalls.

And let's not forget that various parts of that "thin layer" connect to each other in something approaching a partial mesh with no transitive reachability.

While I doubt that it's anywhere near enough to account for all the "MIA" ASNs, nor do we have any way of knowing for sure, but many of those folks cannot get by with private ASNs for those networks for the same reason they can't use RFC1918 space. Others give in and use static routes and double-NATs.

S

Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

53

> What about those that are assigned and used but not [currently] visible
> on the public Internet [i.e., are on other internets]?

Indeed!

On Henk's slide number 5 he states:

"Each AS wants to be able to send traffic to any other AS"

This is NOT true. Many ASes explicitly do *NOT*
want to send traffic to any other AS. They only want
to send traffic to customers, vendors or business
partners of some sort.

You are right, but this was not the point I was trying to make on
this slide.

The point I was trying to make is: A site is assigned an AS if it has a
network that is connected to the global Internet and wants to send traffic somewhere. (If not, why bother to get an AS?) One of the rules in the
policies is that the AS is returned when the need disappears. So, very
naively, I'd think that for each assigned AS there is at least one
path announcing the address space in that AS to somebody else.

I immediately agree that there are cases where an AS does not want to
send traffic to another AS, or prefers not to use a path even though
it is available.

I also agree that there are cases where a network is
not visible at all on the Internet and a private AS cannot be used.
However, I do not believe that these cases account for 1/3 of the AS
out there.

Henk

54

...

Because it is connected to a DIFFERENT internet and wants to send
traffic somewhere.

My point was that the slide makes it sound like it covers ALL ASNs [as
does your text, above], and there is AT LEAST one other possibility.

55

>This is NOT true. Many ASes explicitly do *NOT*
>want to send traffic to any other AS. They only want
>to send traffic to customers, vendors or business
>partners of some sort.

The point I was trying to make is: A site is assigned an AS if it has a
network that is connected to the global Internet and wants to send
traffic somewhere. (If not, why bother to get an AS?)

Many companies get an AS in order to exchange traffic
with other companies across an internetwork that
IS NOT THE GLOBAL INTERNET!!! There are many internetworks
separate from the global Internet. These internetworks
carry traffic between many companies using globally unique
IP addresses and global unique AS numbers. But these companies
do not want any of this traffic to transit any part of the
global Internet and they don't want any form of peering
with the global Internet.

Some people seem to think that IP addresses were created
in order to allow people to run networks connected to
the global Internet and that ASes were invented in order
for such networks to exchange routing policy details on
the global Internet. THIS IS *NOT* TRUE!

IP (Internetwork Protocol) addresses were created to allow
devices to communicate using IP regardless of whether they are
all connected to a single global Internet or not. And AS numbers
were created to allow IP networks to exchange routing policy
details across any IP network, not just the global Internet.

RFC1918 IP addresses were set aside for the special
case in which someone is building a *PRIVATE* network.
Once two organizations interconnect their networks,
the two networks are no longer private and must use
globally unique addresses to avoid conflicts. Similarly
private AS numbers were created for people to build
private internetworks such as in a lab environment or
at the edge of the global Internet where the private
ASes would disappear when routes are aggregated towards
the core. But if many companies wish to connect their
networks in an internetwork, separate from the global
Internet then private AS numbers are required to avoid
conflicts.

So, to answer your question, "Why bother to get an AS?".
In order to exchange routing policy details with other
organizations on one of the many internetworks that
are NOT PART OF THE GLOBAL INTERNET!

It is important for RIR policymakers to understand
that the RIRs are not managing Internet resources.
They are managing IP (Internetwork Protocol) resources
that are absolutely essential for ALL users of IP and
related protocols. These users may not be part of the
Internet but they still have a right to use these resources
in order to build their networks.

One of the rules in the
policies is that the AS is returned when the need disappears.

Excellent rule and it should be more widely enforced.

I also agree that there are cases where a network is
not visible at all on the Internet and a private AS cannot be used.
However, I do not believe that these cases account for 1/3 of the AS
out there.

I agree. I would guess that there are no more than a
few hundred ASes in use on private internetworks. So
that still leaves almost 10,000 ASes that could be
recovered and reused.

On the other hand, it may be cheaper in the long run
to just go to a 4-byte AS number and forget about lost
AS numbers entirely. Is "waste" really a relevant word
when we have IPv6 and 4-byte ASNs on the horizon?

--Michael Dillon

56

> >This is NOT true. Many ASes explicitly do *NOT*
> >want to send traffic to any other AS. They only want
> >to send traffic to customers, vendors or business
> >partners of some sort.

> The point I was trying to make is: A site is assigned an AS if it has a
> network that is connected to the global Internet and wants to send
> traffic somewhere. (If not, why bother to get an AS?)

Many companies get an AS in order to exchange traffic
with other companies across an internetwork that
IS NOT THE GLOBAL INTERNET!!! There are many internetworks
separate from the global Internet. These internetworks
carry traffic between many companies using globally unique
IP addresses and global unique AS numbers. But these companies
do not want any of this traffic to transit any part of the
global Internet and they don't want any form of peering
with the global Internet.

Some people seem to think that IP addresses were created
in order to allow people to run networks connected to
the global Internet and that ASes were invented in order
for such networks to exchange routing policy details on
the global Internet. THIS IS *NOT* TRUE!

IP (Internetwork Protocol) addresses were created to allow
devices to communicate using IP regardless of whether they are
all connected to a single global Internet or not. And AS numbers
were created to allow IP networks to exchange routing policy
details across any IP network, not just the global Internet.

You need to separate technology from implementation. Anybody is free to
use IP-technology to build their own network for which they define their
own policies. What you refer to as the "global internet" is just one
particular implementation with resource-allocation-policies decided by
its users.

With no shortage of resources (in this case AS-numbers and IP-addresses)
we wouldn't have this discussion. Then nobody would care how an
organisation is using the resources that are allocated to them.

Resource-allocation across separate administrative domains doesn't work
when there's a shortage. *If* that happens private networks may need to
establish their own registry for "private ipv4 resources overlapping
with the global internet", so that those resources can be re-used.

RFC1918 IP addresses were set aside for the special
case in which someone is building a *PRIVATE* network.
Once two organizations interconnect their networks,
the two networks are no longer private and must use
globally unique addresses to avoid conflicts. Similarly
private AS numbers were created for people to build
private internetworks such as in a lab environment or
at the edge of the global Internet where the private
ASes would disappear when routes are aggregated towards
the core. But if many companies wish to connect their
networks in an internetwork, separate from the global
Internet then private AS numbers are required to avoid
conflicts.

So, to answer your question, "Why bother to get an AS?".
In order to exchange routing policy details with other
organizations on one of the many internetworks that
are NOT PART OF THE GLOBAL INTERNET!

Nobody is questioning the advantages of globally unique identifiers.
However, administrative resources for the internet are primarily ment to
serve the public. If or when there's a shortage of resources, private
network may have to accept to administer their resources separately.
There is technically no need for these networks to share resources with
the global internet if they have no intention to ever connect to, or
communicates with nodes on, the global network.

It is important for RIR policymakers to understand
that the RIRs are not managing Internet resources.
They are managing IP (Internetwork Protocol) resources
that are absolutely essential for ALL users of IP and
related protocols. These users may not be part of the
Internet but they still have a right to use these resources
in order to build their networks.

Wrong. RIRs have no authority outside the resources they've been
assigned from the global pool, and certainly not over networks not
connected to the global internet. RIR's are (as anybody else) free to
take part in the process of developing global policies.

Anybody is free to build their own separate networks and use
IP-technology as they want, but internet registries have no obligation
to administer their resources.

//Per

57

With no shortage of resources (in this case AS-numbers and IP-addresses)
we wouldn't have this discussion. Then nobody would care how an
organisation is using the resources that are allocated to them.

Thankfully there is no shortage of IP addresses and there
will be no shortage of AS numbers. The factory has already
ramped up production of IPv6 addresses and warehouses are
full. Designs for the new version AS numbers are just about
past engineering review and the factory is ready to begin
production.

Nobody is questioning the advantages of globally unique identifiers.
However, administrative resources for the internet are primarily ment to
serve the public.

And the public *IS* being served by the diversity of
applications and networks which use the Internet
Protocol. The public is served regardless of whether
the device is on a private network, the global Internet
or some other internet.

There is technically no need for these networks to share resources with
the global internet if they have no intention to ever connect to, or
communicates with nodes on, the global network.

This is where you are wrong. Primarily this is because
firewalls make it possible for organizations to run
a network which connects to BOTH the global Internet
and one or more private Internets without allowing any
traffic to transit between these networks or any routing
information to leak between these networks. Nevertheless,
the network in the middle needs to use globally unique
addresses and both RFC 1918 and RFC 2050 explicitly
account for such networks. If a network interconnects
with other networks it is *NOT& a private network and
therefore it requires globally unique identifiers.

Wrong. RIRs have no authority outside the resources they've been
assigned from the global pool, and certainly not over networks not
connected to the global internet. RIR's are (as anybody else) free to
take part in the process of developing global policies.

RIRs have no authority over networks connected to
the global Internet either. RIRs are part of a system
of self-regulation, not government regulation, and therefore
have no authority other than the consent of their members.

Anybody is free to build their own separate networks and use
IP-technology as they want, but internet registries have no obligation
to administer their resources.

You seem to think that the Internet was created before there
were nascent RIRs managing internet numbering. It was the other
way around. Right from the beginning when IP, the internetwork
protocol, was designed, there was an understanding of the need
to COORDINATE numbering resources. After a while, so many of
the young internetworks connected together that people started
to think and speak of one single global Internet. This is a
nice result but IP does not belong to *ONLY* those organizations
who connect to the global Internet. It is more general than that.

Even though the Internet is the major revenue source for most
of the companies in which NANOG members work, these companies
also operate important IP networks which are *NOT* the Internet.
It is important to remember this, especially when talking about
ARIN and other RIRs, ICANN, the IETF, etc. None of these
organizations serve the global Internet exclusively. They serve
the body of protocols which make the Internet, and other internets,
possible.

--Michael Dillon

58

> With no shortage of resources (in this case AS-numbers and IP-addresses)
> we wouldn't have this discussion. Then nobody would care how an
> organisation is using the resources that are allocated to them.

Thankfully there is no shortage of IP addresses and there
will be no shortage of AS numbers. The factory has already
ramped up production of IPv6 addresses and warehouses are
full. Designs for the new version AS numbers are just about
past engineering review and the factory is ready to begin
production.

> Nobody is questioning the advantages of globally unique identifiers.
> However, administrative resources for the internet are primarily ment to
> serve the public.

And the public *IS* being served by the diversity of
applications and networks which use the Internet
Protocol. The public is served regardless of whether
the device is on a private network, the global Internet
or some other internet.

> There is technically no need for these networks to share resources with
> the global internet if they have no intention to ever connect to, or
> communicates with nodes on, the global network.

This is where you are wrong. Primarily this is because
firewalls make it possible for organizations to run
a network which connects to BOTH the global Internet
and one or more private Internets without allowing any
traffic to transit between these networks or any routing
information to leak between these networks. Nevertheless,
the network in the middle needs to use globally unique
addresses and both RFC 1918 and RFC 2050 explicitly
account for such networks. If a network interconnects
with other networks it is *NOT& a private network and
therefore it requires globally unique identifiers.

... which is why I specifically said "no intention to ever connect to,
or communicates with nodes on, the global network". In which case
overlaps in adressblocks are irrelevant, as are any mention of NAT and
firewalls as there is no connection (direct or indirect) between the
networks.

> Wrong. RIRs have no authority outside the resources they've been
> assigned from the global pool, and certainly not over networks not
> connected to the global internet. RIR's are (as anybody else) free to
> take part in the process of developing global policies.

RIRs have no authority over networks connected to
the global Internet either. RIRs are part of a system
of self-regulation, not government regulation, and therefore
have no authority other than the consent of their members.

Authority wasn't the right word perhaps :wink: "Operating context" may be a
better term.

> Anybody is free to build their own separate networks and use
> IP-technology as they want, but internet registries have no obligation
> to administer their resources.

You seem to think that the Internet was created before there
were nascent RIRs managing internet numbering.

Nope, when I started networking there was no global network worth
connecting to and sna, decnet or ipx nodes worldwide outnumbered ip by
1000 to one or more. RFC1918 wasn't even on the horizon and there were
lots of ad-hoc built IP networks using randomly selected addresses.
Internet governance was handled by handful of people in IANA.

It was the other
way around. Right from the beginning when IP, the internetwork
protocol, was designed, there was an understanding of the need
to COORDINATE numbering resources. After a while, so many of
the young internetworks connected together that people started
to think and speak of one single global Internet. This is a
nice result but IP does not belong to *ONLY* those organizations
who connect to the global Internet. It is more general than that.

Sure, and that's why you need to separate between the technology
administered through the IETF and *one* particular implementation of it
which happen to be coordinated by a hierarchy of organisations under the
"ICANN-umbrella". Those who don't want to take part in this hierarchy or
communicate with it's network are free to organise their own in whatever
way they please.

Even though the Internet is the major revenue source for most
of the companies in which NANOG members work, these companies
also operate important IP networks which are *NOT* the Internet.
It is important to remember this, especially when talking about
ARIN and other RIRs, ICANN, the IETF, etc. None of these
organizations serve the global Internet exclusively. They serve
the body of protocols which make the Internet, and other internets,
possible.

technology != implementation

//Per

59

I am currently tasked with upgrading our network to a dual-stack IPv4/IPv6 architecture. At the beginning of this project, I assumed the difficult part would be with the router upgrades, programming, etc. So far, that has been the easy part.

Does anyone know of _any_ defaultless SFP providers (a.k.a. Tier 1) that support dual-stack IPv4/IPv6 BGP sessions? We currently have three transit connections for IPv4 (all to Tier 1 providers). "upgrading" those to IPv4/IPv6 doesn't appear possible as those three providers tell me they can't do IPv6 yet.

Given our growth rate, it is quite possible we will need another transit DS3 in less than a year. If I can find a transit provider with IPv6 in St. Louis/Kansas City, that may decide our next choice.

To avoid vendor wars on the list, please send vendor recommendations directly to me.

John

60

... which is why I specifically said "no intention to ever connect to,
or communicates with nodes on, the global network". In which case
overlaps in adressblocks are irrelevant, as are any mention of NAT and
firewalls as there is no connection (direct or indirect) between the
networks.

The only case that I am aware of where there is truly
*NO* intention to ever connect to the global Internet
is military networks. When I was referring to other
internets I did not have military networks in mind.

In every other case that I am aware of, the partcipants
in the internet also maintain connectivity to the Internet
via alternate paths.

--Michael Dillon