in
English. That document recommends that a hyphen, space or period be
used to provide visual separation between groups of numbers;
parentheses are to be used for sections of the number which are
sometimes not dialled, but not in the full international notation
which includes an E.164 country
On 3-Oct-2006, at 08:53, Joe Abley wrote:
E.123 also tells us how to write our e-mail addresses and URLs on
business cards, except that it calls URLs web addresses. At
least, this is what I can glean from the many E.123 summaries I
could find, since the actual document isn't available
codes,
I suspect it's easier to type number dot number rather than plus number
parenthesis number parenthesis number hyphen number and so on. I
converted all my phone list numbers to that format long ago. It's just
cleaner. Never thought about whether it was cool, or not. Cool is not
on my radar
-Address-Wannabe method, like:
206.555.1212
Commas in AT commands and on fax machines mean pause. Not sure why space
isn't a good enough separator for phone numbers.
Periods are used as separators for sequences of three numbers
conventionally in most European (ie continental) countries likewise
.
It's normal in a lot of places. When you start to add in country codes,
I suspect it's easier to type number dot number rather than plus number
parenthesis number parenthesis number hyphen number and so on. I
converted all my phone list numbers to that format long ago. It's just
cleaner. Never
Bon soir,
} On Fri, 5 May 2006, Aleksi Suhonen wrote:
} A) does not pass a peering relationship
}(i.e. is AS internal or passes through transit connections only)
} B) passes a public peering relationship
} C) passes a private peering relationship
Mikael Abrahamsson wrote:
} Judging from
ports usually cost 3-8x more
* Larger numbers of smaller peers * Smaller numbers of larger peers
* Lots of language specific content * Lots of globally targetted content
Obviously market economics drive public peering much more in Europe than
in the US. To put it into perspective
on new tech
* IX ports are generally very cheap * Same ports usually cost 3-8x more
* Larger numbers of smaller peers * Smaller numbers of larger peers
* Lots of language specific content * Lots of globally targetted content
Obviously market economics drive public peering much more
Hello,
I wonder if anyone has done any estimates on how many
percent of the Internet traffic:
A) does not pass a peering relationship
(i.e. is AS internal or passes through transit connections only)
B) passes a public peering relationship
C) passes a private peering relationship
I know this
Fergie wrote:
Given all the noise that this issue has caused on the list, I
thought I'd take a moment this afternoon and forward a URL that
good folks over at LURHQ have made available with more realistic,
and current, statistics on the BlackWorm cruft:
if one is looking at origin-as in routing annoucements in route views,
there are some asns that should be ignored, e.g., . is there a
good list of these somewhere.
randy
):
Sorry for the late response, but I got some numbers in Japan.
(1) httpd access logs of www.kame.net
In 24-hour access logs on September 13, there are 148 unique IPv6
addresses within 1,849 unique IPv4 and IPv6 addresses.
So, about 8.0% is IPv6.
The breakdown of IPv6 address blocks:
2001
less
There may be similar statistics for Geant - I would be interested to
see them.
I'll look up the GEANT numbers in a minute, stay tuned.
--
Simon.
is correct. The numbers I quoted were for protocol 41 traffic,
and presumably more IPv6 is hidden in plain sight on the Internet 2
backbone.
Sorry for the confusion.
Regards
Marshall
While I'm also skeptical about the representativeness of Jordi's
estimates, this is a bad counterexample (see
On 31.07 17:20, [EMAIL PROTECTED] wrote:
we did that (move a root) in the CIDR /8 experiment.
we could do it for this too :)
one root name server: yes
the root name servers: no, definitely not
Daniel
PS: Ony as soon as implementations are available of course ! ;-(
On Mon, Aug 01, 2005 at 09:17:58AM +0200, Daniel Karrenberg wrote:
On 31.07 17:20, [EMAIL PROTECTED] wrote:
we did that (move a root) in the CIDR /8 experiment.
we could do it for this too :)
one root name server: yes
the root name servers: no, definitely not
Daniel
On Sun, 31 Jul 2005, Geoff Huston wrote:
So - to NANOG at large - if you want your vendor to include 4-Byte AS support
in their BGP code anytime soon, in order to avoid some last minute panic in a
couple of years hence, then it would appear that you should talk to them now
and say clearly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone who uses the argument of inter-domain routing that are not
seen by
any data collectors on the Internet should be pointed at RFC1930
and told
to renumber their private ASNs.
Just because public route collectors can't see use of an
On 1 Aug 2005, at 06:15, Stephen J. Wilcox wrote:
On Sun, 31 Jul 2005, Geoff Huston wrote:
So - to NANOG at large - if you want your vendor to include 4-Byte AS
support
in their BGP code anytime soon, in order to avoid some last minute
panic in a
couple of years hence, then it would
At 08:15 PM 1/08/2005, Stephen J. Wilcox wrote:
On Sun, 31 Jul 2005, Geoff Huston wrote:
So - to NANOG at large - if you want your vendor to include 4-Byte AS
support
in their BGP code anytime soon, in order to avoid some last minute
panic in a
couple of years hence, then it would appear
On Tue, 2 Aug 2005, Geoff Huston wrote:
There is a draft draft-ietf-idr-as4bytes-10.txt- it is a draft because
under the current IETF procedures there needs to be 2 independent
implementations of the specification, and at the moment only Redback's
BGP has implemented this. Once there is a
-byte AS number support,
regardless of how many 2-byte AS numbers they already have. ISPs who
plan to stop getting new customers don't need to bother :-)
Joe
to _demand_ it? Maybe...
ISPs who have an interest in continuing to win transit customers past
2008/2009 should be interested in getting 4-byte AS number support,
regardless of how many 2-byte AS numbers they already have. ISPs who plan
to stop getting new customers don't need to bother
/2009 should be interested in getting 4-byte AS number
support, regardless of how many 2-byte AS numbers they already have.
ISPs who plan to stop getting new customers don't need to bother :-)
As new /8's of address space are going up, various folks on NANOG
have asked for test addresses within
Given the interest in whether 4 byte AS numbers will function, when
will a test network be put up using a 4 byte AS, and announced so
that everyone can test their readiness?
A server hosted on such a network probably could produce a weekly
report, similar to the CIDR report, that shows
[EMAIL PROTECTED] wrote:
nice... so one or more of the RIRs should ask the IANA
for a delegation in the 4byte space and let a few
brave souls run such a trap. The IETF has a proces
for running such experiments that could be applied here.
should I write it up
Given the interest in whether 4 byte AS numbers will function, when
will a test network be put up using a 4 byte AS, and announced so
that everyone can test their readiness?
A server hosted on such a network probably could produce a weekly
report, similar
On Sun, Jul 31, 2005 at 08:08:37PM +0300, Petri Helenius wrote:
[EMAIL PROTECTED] wrote:
nice... so one or more of the RIRs should ask the IANA
for a delegation in the 4byte space and let a few
brave souls run such a trap. The IETF has a proces
for
. Anything not seen after a year (15-20%),
is unlikely to ever appear, these can be recovered (at least in theory).
While this looks like a lot, it does not really solve any problem. Geoff's
numbers show that the pool will expire in 5 years. Our estimate is a
little bit longer, but not that much
On Sat, 30 Jul 2005, Daniel Karrenberg wrote:
The RIPE NCC has hit strong resistance to reclamation, most often with
the argument that the ASes are used in inter-domain routing on the
Internet but our BGP data collectors just do not see the paths
concerned. It takes considerable effort to
On 30 Jul 2005, at 15:03, Hank Nussbacher wrote:
On Sat, 30 Jul 2005, Daniel Karrenberg wrote:
The RIPE NCC has hit strong resistance to reclamation, most often with
the argument that the ASes are used in inter-domain routing on the
Internet but our BGP data collectors just do not see the
soone - they can still exist in a
mixed 2 / 4 byte AS world (the only change that may have some minor impact
is the issue of embedding AS numbers in BGP communities, in which case
support for extended communities is necessary.
So it appears to me that the 'piecemeal' transition will work well
of us already have a 2-Byte AS so although we care in theory and
believe it is a good idea, we don't _really_ care as much as the first guy
who gets a 4-Byte AS will. Eventually one of our BGP speaking transit
customers will be assigned these AS numbers and other newer providers will
too
geoff has a quite good article on antonymous systems, usage, ... at
http://www.potaroo.net/ispcol/2005-08/as.html.
randy
geoff has a quite good article on antonymous systems, usage, ... at
http://www.potaroo.net/ispcol/2005-08/as.html.
geoff,
why not assume
o all speakers will not transition at the same time, but
o before the first 0: is issued/used that all will
transition?
i would think this is
On Fri, 29 Jul 2005, Randy Bush wrote:
Geoff,
Of the 32,557 assigned AS numbers, some 19,859 are advertised, while
12,698 have been allocated in the past, but are not currently advertised
in the BGP routing table.
I would have liked to see how well the RIRs are at recovering unused
ASNs
Hank,
At 09:13 29/07/2005, Hank Nussbacher wrote:
Of the 32,557 assigned AS numbers, some 19,859 are advertised, while
12,698 have been allocated in the past, but are not currently advertised
in the BGP routing table.
I would have liked to see how well the RIRs are at recovering unused
ASNs
On Fri, 29 Jul 2005, Henk Uijterwaal wrote:
While this looks like a lot, it does not really solve any problem. Geoff's
numbers show that the pool will expire in 5 years. Our estimate is a
When discussed a few years back, I was told that this was already solved
by 32bit AS numbers
Henk Uijterwaal wrote:
While this looks like a lot, it does not really solve any problem.
Geoff's numbers show that the pool will expire in 5 years. Our
estimate is a little bit longer, but not that much. 2010-2005 is 5
years, if the trend that 20% never appears continues and all these
ASN
While this looks like a lot, it does not really solve any problem. Geoff's
numbers show that the pool will expire in 5 years. Our estimate is a
When discussed a few years back, I was told that this was already solved
by 32bit AS numbers (ASx:x).
you may want to read the referenced
On Fri, 29 Jul 2005, Randy Bush wrote:
you may want to read the referenced article
http://www.potaroo.net/ispcol/2005-08/as.html
The article states it's not fixed. I guess what I was told back then was
false, considering
http://en.wikipedia.org/wiki/Autonomous_system_(Internet) states:
The article states it's not fixed.
that seems to agree with at least one of my routers
rtr42#conf t
Enter configuration commands, one per line. End with CNTL/Z.
rtr42(config)#router bgp 0:3130
^
% Invalid input detected at '^' marker.
my point was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
This is to inform you that the IANA has allocated the following
block of AS Numbers to AfriNIC:
36864 - 37887
For a full list of IANA AS Number allocations please see
http://www.iana.org/assignments/as-numbers
- --
Doug Barton
General
Not really the right forum for this, but the kindo f thing nanog'ers know:
Is there a way to make Linux ignore TCP sequence numbers?
My goal is to be able to have a test network with servers that a point
real traffic at, mirrored off the live network.
Of course, only the live servers
Steve Francis wrote:
Not really the right forum for this, but the kindo f thing nanog'ers
know:
Is there a way to make Linux ignore TCP sequence numbers?
You want to RTFS tcp_data_queue in tcp_input.c. However, even if you get
what you ask for you don't get what you wish to accomplish.
Pete
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is to inform you that the IANA has allocated the following
block of AS Numbers to ARIN:
32768 - 33791
For a full list of IANA AS Number allocations please see
http://www.iana.org/assignments/as-numbers
- --
Doug Barton
General Manager
Historic moment. 32k+ ASN assignments are coming!
On Fri, 28 May 2004, Doug Barton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is to inform you that the IANA has allocated the following
block of AS Numbers to ARIN:
32768 - 33791
For a full list of IANA AS Number
http://www.nwfusion.com/news/2004/0517specialfocus.html
-Hank
PS I can think of yet another metric that can be measured at the SRDM-BOF
at the next NANOG :-)
On Wed, 13 Aug 2003, Iljitsch van Beijnum wrote:
It's not the same thing. RFC 1918 and martian addresses aren't supposed
to be present on the internet, but aren't automatically harmful. Having
services that are explicitly labeled for internal use be visible to the
rest of the world is
On woensdag, aug 13, 2003, at 21:38 Europe/Amsterdam, Crist Clark wrote:
Cool. So if you use private ports, you'll be totally protected from the
Internet nasties (and the Internet protected from your broken or
malicious
traffic) in the same way RFC1918 addressing does the exact same thing
now
Lars Higham wrote:
It's a good idea, granted, but isn't this covered by IPv6 administrative
scoping?
That's the network layer, not the transport layer. IPv6 scoping has the
potential to be very helpful for private addressing since it's fundamentally
built into the protocol, as opposed to
On Wed, Aug 13, 2003 at 10:40:30PM +, Christopher L. Morrow quacked:
what about ports that start as 'private' and are eventually ubiquitously
used on a public network? (Sean Donelan noted that 137-139 were
originally intended to be used in private networks... and they became
'public'
On Wed, 13 Aug 2003, Crist Clark wrote:
Iljitsch van Beijnum wrote:
Be damned if you filter, be damned if you don't. Nice choice.
I think it's time that we set aside a range of port numbers for private
use. That makes all those services that have no business escaping out
Subject: Re: Private port numbers? Date: Thu, Aug 14, 2003 at 11:41:25AM -0700 Quoting
Crist Clark ([EMAIL PROTECTED]):
Lars Higham wrote:
It's a good idea, granted, but isn't this covered by IPv6 administrative
scoping?
That's the network layer, not the transport layer. IPv6 scoping
Iljitsch van Beijnum wrote:
Be damned if you filter, be damned if you don't. Nice choice.
I think it's time that we set aside a range of port numbers for private
use. That makes all those services that have no business escaping out
in the open extremely easy to filter, while at the same
Mans Nilsson wrote:
Subject: Re: Private port numbers? Date: Thu, Aug 14, 2003 at 11:41:25AM -0700
Quoting Crist Clark ([EMAIL PROTECTED]):
Lars Higham wrote:
It's a good idea, granted, but isn't this covered by IPv6 administrative
scoping?
That's the network layer
The IETF IPNG WG home page can be found at:
http://playground.sun.com/ipng
The decision regarding site-local was made during the San
Francisco IETF meeting and then later confirmed on the mailing lists
although there has been quite some debate over it all since
57 matches
Mail list logo
