RE: experience with equinix exchange

[Ryan Finnesey]

I would like to know the issues as well because we are looking to going
into at least 4 of their centers.
Cheers
Ryan


-Original Message-
From: Robert E. Seastrom [mailto:r...@seastrom.com] 
Sent: Friday, November 19, 2010 3:30 AM
To: Justin Horstman
Cc: nanog@nanog.org; Mehmet Akcin
Subject: Re: experience with equinix exchange


Paul is pretty clueful; I think he was asking for specifics as to what
the layer 8/9 issues are at Equinix, rather than an explanation of what
layer 8 and 9 means.

"Fly Fast",

-r


Justin Horstman  writes:

> 8 users
> 9 politics and policies
>
>> -Original Message-
>> From: Paul WALL [mailto:pauldotw...@gmail.com]
>> Sent: Thursday, November 18, 2010 10:55 AM
>> To: Mehmet Akcin
>> Cc: nanog@nanog.org
>> Subject: Re: experience with equinix exchange
>> 
>> What are the layer 8-9 issues?
>> 
>> Drive Slow,
>> Paul Wall
>> 
>> On Thu, Nov 18, 2010 at 12:50 AM, Mehmet Akcin 
>> wrote:
>> >
>> > On Nov 18, 2010, at 12:48 PM, Shacolby Jackson wrote:
>> >
>> >> Has anyone had any experience (good or bad) with their exchange at
>> any of
>> >> their major datacenters, especially Great Oaks? We're wondering if
>> people
>> >> really love or hate it.
>> >>
>> >> -shac
>> >
>> >
>> > Equinix does a fair job running 7 layers , however the layer8 and
>> layer9 seem the lacking part
>> > which could have been improved greatly. in Great Oaks / SJC , they
>> seem to be the largest IX
>> >
>> > per
>> >
>> >
>> https://www.peeringdb.com/private/exchange_view.php?id=5&peerParticip
>> an tsPublicsOrder=Sorter_policy&peerParticipantsPublicsDir=DESC
>> >
>> > so being there while you are in that location seems good, and they
>> are reliable.
>> >
>> > mehmet
>> >

Re: IPv6 6to4 and dns

[Mark Andrews]

In message <4ce6d919.2000...@mompl.net>, Jeroen van Aart writes:
> Mark Andrews wrote:
> > Firstly I would use a tunnel broker instead of 6to4.  Easier to
> > debug failures.
> 
> Thanks all for the helpful response. Using the same names for IPv6 and 
> IPv4 doesn't appear to be much of a problem, especially considering this 
> is a trial which concerns office/home ISP connectivity, for now.
> 
> Which IPv6 tunnel broker is preferable, or does it really matter?

I've been using HE for 7 years now and have always got a fast response
when I've had problems with the link.

> Thanks,
> Jeroen
> 
> -- 
> http://goldmark.org/jeff/stupid-disclaimers/
> http://linuxmafia.com/~rick/faq/plural-of-virus.html
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Introducing draft-denog-v6ops-addresspartnaming

[William Herrin]

On Fri, Nov 19, 2010 at 4:20 PM, Richard Hartmann
 wrote:
> On Fri, Nov 19, 2010 at 21:45, William Herrin  wrote:
>> I have an anti-naming proposal: Allow users to place the colons
>> -anywhere- or even leave them out altogether without changing the
>> semantics of the IPv6 address.
>
> A decade or two of established syntax disagree. IPv6 addresses, UUIDs
> and similar have a unique syntax for a reason. Otherwise, we, nor
> computers, wouldn't be able to quickly distinguish an IP from a hash.

Hi Richard,

I thought about that. Have a "one colon rule" that IPv6 addresses in
hexidecimal format have to include at least one colon somewhere. The
regex which picks that token out versus the other possibilities is
easy enough to write and so is the human rule: "Oh, it's got
hexidecimal digits and a colon in it. IPv6 address."

There is one serious problem with switching notations: we've already
started dropping the leading 0's inside each coloned-off section, and
that would have a different meaning if the colons could be placed
anywhere.

fd00:68::1 and fd:0068::1 mean different things now. The former means
fd00:0068::1 while the latter means 00fd:0068::1. I would instead have
them mean the same thing: fd00:6800::1. The single-colon separator
gets syntax but no semantics and the :: separator means "all middle
nibbles are zero" instead of "all middle two-byte components are
zero."

I mean, when you think about it, the consequence that :: means "all
middle two-byte components are zero" is kinda weird.

> Even if they were for readability only, they would still be for
> humans. Same as the specific, canonical name we are trying to agree
> on.
>
> If people want to interpret more into the colons than there is to see,
> they will do so regardless of a name.

Anything you call out will be interpreted as special. The more you
call it out, the greater the expectation that the distinction is
important. That's human nature.

You've explained netmasks before to folks whose brains couldn't get
past the dots in the address. We all have. And referring to IP address
notation as "dotted quads" just reinforces classful addressing
concepts so that folks assigning themselves 10/8 subnets damn near
always split on /16 and /24 boundaries.


> The rest of us will work faster, more efficiently and not explain the
> same old thing a gazillion times.

And even more efficiently when we don't have to repeatedly explain
that the mental model implied by the notation style is, in fact, not
how the technology actually works.


On Fri, Nov 19, 2010 at 4:31 PM, Richard Hartmann
 wrote:
> In any case, other than "some people might see the colons as magic
> markers" I don't really see an argument in favour of avoiding a common
> name. And that does not seem to hold much water. This is not meant to
> be an attack, I simply wonder if I am missing something.

No sweat. When I shoot my mouth off, I expect to be challenged on the
remarks. Part of the fun lies in discovering whether the thesis is
defensible.

By the by, as long as I'm criticizing IPv6 notation, let me express
just how poor a choice of separator character the colon is. The colon
separates the IPv4 address from a directory or port description only
slightly less often than the slash. Writing the parsers to handle an
IPv6 address as a drop in is a pain in the tail. Should have used a
dash, underscore or plus. Those are far more rarely used in
tokenization.

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

The Cidr Report

[cidr-report]

This report has been generated at Fri Nov 19 21:11:36 2010 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
12-11-10340330  208586
13-11-10340655  208589
14-11-10340682  208704
15-11-10340909  208908
16-11-10340981  208978
17-11-10340973  209903
18-11-10342729  209359
19-11-10341575  209115


AS Summary
 36005  Number of ASes in routing system
 15383  Number of ASes announcing only one prefix
  4547  Largest number of prefixes announced by an AS
AS4323 : TWTC - tw telecom holdings, inc.
  101649920  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 19Nov10 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 341301   209145   13215638.7%   All ASes

AS6389  3746  444 330288.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS4323  4547 1735 281261.8%   TWTC - tw telecom holdings,
   inc.
AS6503  2011  431 158078.6%   Axtel, S.A.B. de C.V.
AS19262 1837  405 143278.0%   VZGNI-TRANSIT - Verizon Online
   LLC
AS4766  1738  586 115266.3%   KIXS-AS-KR Korea Telecom
AS17488 1365  264 110180.7%   HATHWAY-NET-AP Hathway IP Over
   Cable Internet
AS4755  1390  362 102874.0%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS22773 1251  312  93975.1%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS18566 1092  158  93485.5%   COVAD - Covad Communications
   Co.
AS24560 1057  203  85480.8%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS10620 1336  497  83962.8%   Telmex Colombia S.A.
AS33363 1570  778  79250.4%   BHN-TAMPA - BRIGHT HOUSE
   NETWORKS, LLC
AS28573 1157  369  78868.1%   NET Servicos de Comunicao S.A.
AS18101  903  150  75383.4%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS7545  1439  699  74051.4%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS8151  1350  718  63246.8%   Uninet S.A. de C.V.
AS4808   926  296  63068.0%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS8452  1067  446  62158.2%   TE-AS TE-AS
AS17676  640   66  57489.7%   GIGAINFRA Softbank BB Corp.
AS7303   827  267  56067.7%   Telecom Argentina S.A.
AS22047  563   31  53294.5%   VTR BANDA ANCHA S.A.
AS4780   710  209  50170.6%   SEEDNET Digital United Inc.
AS9443   571   76  49586.7%   INTERNETPRIMUS-AS-AP Primus
   Telecommunications
AS7552   632  144  48877.2%   VIETEL-AS-AP Vietel
   Corporation
AS1785  1805 1320  48526.9%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS11492 1258  783  47537.8%   CABLEONE - CABLE ONE, INC.
AS14420  572  101  47182.3%   CORPORACION NACIONAL DE
   TELECOMUNICACIONES - CNT EP
AS4804   544   76  46886.0%   MPX-AS Microplex PTY LTD
AS36992  652  192  46070.6%   ETISALAT-MISR
AS3356  1190  740  45037.8%   LEVEL3 Level 3 Communications

Total  39746128582688867.6%   Top 30 total


Possible Bogus Routes

31.0.0.0/16  AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project
31.1.0.0/21  AS12654 RIPE-NCC-RIS-AS RIPE NCC

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 11-Nov-10 -to- 18-Nov-10 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS14420   27730  2.2%  48.5 -- CORPORACION NACIONAL DE 
TELECOMUNICACIONES - CNT EP
 2 - AS947626352  2.1%8784.0 -- INTRAPOWER-AS-AP IntraPower 
Pty. Ltd.
 3 - AS32528   22045  1.8%5511.2 -- ABBOTT Abbot Labs
 4 - AS553617634  1.4% 176.3 -- Internet-Egypt
 5 - AS982917096  1.4%  42.5 -- BSNL-NIB National Internet 
Backbone
 6 - AS15978   15197  1.2%5065.7 -- BOBST Group autonomous system
 7 - AS815115072  1.2%   7.5 -- Uninet S.A. de C.V.
 8 - AS949813496  1.1% 131.0 -- BBIL-AP BHARTI Airtel Ltd.
 9 - AS701 12968  1.0% 254.3 -- UUNET - MCI Communications 
Services, Inc. d/b/a Verizon Business
10 - AS359319995  0.8%3331.7 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
11 - AS178038320  0.7%  20.1 -- BSES-AS-AP BSES TeleCom Limited
12 - AS6316 7081  0.6% 321.9 -- AS-PAETEC-NET - PaeTec 
Communications, Inc.
13 - AS221856954  0.6%1159.0 -- TELEFONICA-UNIDAD LARGA 
DISTANCIA
14 - AS369926857  0.6%  11.4 -- ETISALAT-MISR
15 - AS223946838  0.6%  14.7 -- CELLCO - Cellco Partnership DBA 
Verizon Wireless
16 - AS117736624  0.5%  38.5 -- UTMDACC - University of Texas 
M.D. Anderson Cancer Center
17 - AS6503 6585  0.5%   5.1 -- Axtel, S.A.B. de C.V.
18 - AS7545 6471  0.5%   9.6 -- TPG-INTERNET-AP TPG Internet 
Pty Ltd
19 - AS3816 6437  0.5%  45.3 -- COLOMBIA TELECOMUNICACIONES 
S.A. ESP
20 - AS290496434  0.5%  21.7 -- DELTA-TELECOM-AS Delta Telecom 
LTD.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS947626352  2.1%8784.0 -- INTRAPOWER-AS-AP IntraPower 
Pty. Ltd.
 2 - AS485615561  0.5%5561.0 -- AUTOMIR-AS NP Automir CJSC
 3 - AS32528   22045  1.8%5511.2 -- ABBOTT Abbot Labs
 4 - AS15978   15197  1.2%5065.7 -- BOBST Group autonomous system
 5 - AS359319995  0.8%3331.7 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 6 - AS159842255  0.2%2255.0 -- The Joint-Stock Commercial Bank 
CentroCredit.
 7 - AS496002232  0.2%2232.0 -- LASEDA La Seda de Barcelona, S.A
 8 - AS311462083  0.2%2083.0 -- EBNER-AS Ebner Industrieofenbau 
Ges.m.b.H.
 9 - AS407723912  0.3%1956.0 -- VELOCITER-WIRELESS-INC - 
Velociter Wireless, Inc.
10 - AS179041397  0.1%1397.0 -- SLTASUL-LK Sri Lankan Airlines
11 - AS221856954  0.6%1159.0 -- TELEFONICA-UNIDAD LARGA 
DISTANCIA
12 - AS9929 4551  0.4%1137.8 -- CNCNET-CN China Netcom Corp.
13 - AS9556 3302  0.3%1100.7 -- ADAM-AS-AP Adam Internet Pty Ltd
14 - AS356301042  0.1%1042.0 -- ACCENTURE-AS Accenture, Madrid
15 - AS369611025  0.1%1025.0 -- ZIPNET
16 - AS9503 4021  0.3% 804.2 -- FX-PRIMARY-AS FX Networks 
Limited
17 - AS11633 765  0.1% 765.0 -- 4LIFERESEARCHUSALLC - 4Life 
Research USA, LLC
18 - AS51044 751  0.1% 751.0 -- SP-AVIOR-TELECOM-AS OOO SP 
Avior Telecom
19 - AS7619 1363  0.1% 681.5 -- NRL-AS-AP 18th Floor, 
MassMutual Tower,
20 - AS44917 618  0.1% 618.0 -- NN-KBKA-AS KB Kommutatcionnoy 
Apparatury LTD


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 203.1.14.0/24 14714  1.1%   AS9476  -- INTRAPOWER-AS-AP IntraPower 
Pty. Ltd.
 2 - 202.92.235.0/24   12525  0.9%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 3 - 203.1.13.0/24 11635  0.9%   AS9476  -- INTRAPOWER-AS-AP IntraPower 
Pty. Ltd.
 4 - 65.208.172.0/24   11154  0.8%   AS701   -- UUNET - MCI Communications 
Services, Inc. d/b/a Verizon Business
 5 - 130.36.34.0/2411019  0.8%   AS32528 -- ABBOTT Abbot Labs
 6 - 130.36.35.0/2411018  0.8%   AS32528 -- ABBOTT Abbot Labs
 7 - 216.126.136.0/22   6923  0.5%   AS6316  -- AS-PAETEC-NET - PaeTec 
Communications, Inc.
 8 - 63.211.68.0/22 6504  0.5%   AS35931 -- ARCHIPELAGO - ARCHIPELAGO 
HOLDINGS INC
 9 - 190.65.228.0/225663  0.4%   AS3816  -- COLOMBIA TELECOMUNICACIONES 
S.A. ESP
10 - 195.2.198.0/23 5561  0.4%   AS48561 -- AUTOMIR-AS NP Automir CJSC
11 - 195.95.141.0/245067  0.4%   AS15978 -- BOBST Group autonomous system
12 - 195.141.217.0/24   5065  0.4%   AS15978 -- BOBST Group autonomous system
13 - 195.189.204.0/23   5065  0.4%   AS15978 -- BOBST Group autonomous system
14 - 202.83.96.0/20 3640  0.3%   AS18106 -- VIEWQWEST-SG-AP Viewqwest Pte 
Ltd
 AS9255  -- CONNECTPLUS-AS Singapore Telecom
15 - 206.184.16.0/243411  0.2% 

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 22:17, William Herrin  wrote:

> Bit, nibble and /64 then. /64 is treated specially by functions in the
> protocol (like SLAAC) thus it's a protocol boundary rather than a
> social one (/12 IANA allocations, /32 ISP allocations, /48 end-user
> assignments).

I would argue that /0 and /128 are somewhat special, too.


> Unless you particularly feel the need to assign /64's to router
> loopbacks, you'll see plenty of routes longer than /64 in your table
> too.

That's a personal preference, really. Unless you mess up, or are an
end user permanently stuck with a /64 (in which case your ISP messed
up), there isn't really much need to assign anything longer, though.
That being said, for whatever reason, several of my upstreams use /126
for their sessions.


In any case, other than "some people might see the colons as magic
markers" I don't really see an argument in favour of avoiding a common
name. And that does not seem to hold much water. This is not meant to
be an attack, I simply wonder if I am missing something.


Richard

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 21:45, William Herrin  wrote:

> I have an anti-naming proposal: Allow users to place the colons
> -anywhere- or even leave them out altogether without changing the
> semantics of the IPv6 address.

A decade or two of established syntax disagree. IPv6 addresses, UUIDs
and similar have a unique syntax for a reason. Otherwise, we, nor
computers, wouldn't be able to quickly distinguish an IP from a hash.


> The colons are there for readability purposes only. They have no
> special significance and should not be elevated to significance by
> naming the parts of the address they delineate. Treat them specially
> and some fools will attach importance to arranging tasks on two-byte
> boundaries.

Even if they were for readability only, they would still be for
humans. Same as the specific, canonical name we are trying to agree
on.

If people want to interpret more into the colons than there is to see,
they will do so regardless of a name.

The rest of us will work faster, more efficiently and not explain the
same old thing a gazillion times.


Richard

Re: Introducing draft-denog-v6ops-addresspartnaming

[William Herrin]

On Fri, Nov 19, 2010 at 4:09 PM, Joel Jaeggli  wrote:
> On 11/19/10 12:45 PM, William Herrin wrote:
>> The meaningful boundaries in the protocol itself are nibble and /64.
>> If you want socially significant boundaries, add /12, /32 and /48.
>
> It is possible and desirable to be able to describe any mask length
> between /0 and /128. the /64 is an important demarcation point for
> subnets but everything shorter than that will appear in your routing table.

Hi Joel,

Bit, nibble and /64 then. /64 is treated specially by functions in the
protocol (like SLAAC) thus it's a protocol boundary rather than a
social one (/12 IANA allocations, /32 ISP allocations, /48 end-user
assignments).

Unless you particularly feel the need to assign /64's to router
loopbacks, you'll see plenty of routes longer than /64 in your table
too.

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Introducing draft-denog-v6ops-addresspartnaming

[Joel Jaeggli]

On 11/19/10 12:45 PM, William Herrin wrote:
> On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann
>  wrote:
>> as most of you are aware, there is no definite, canonical name for the
>> two bytes of IPv6 addresses between colons. This forces people to use
>> a description like I just did instead of a single, specific term.
> 
> Hi Richard,
> 
> I have an anti-naming proposal: Allow users to place the colons
> -anywhere- or even leave them out altogether without changing the
> semantics of the IPv6 address.
> 
> The colons are there for readability purposes only. They have no
> special significance and should not be elevated to significance by
> naming the parts of the address they delineate. Treat them specially
> and some fools will attach importance to arranging tasks on two-byte
> boundaries.
> 
> The meaningful boundaries in the protocol itself are nibble and /64.
> If you want socially significant boundaries, add /12, /32 and /48.

It is possible and desirable to be able to describe any mask length
between /0 and /128. the /64 is an important demarcation point for
subnets but everything shorter than that will appear in your routing table.

> Regards,
> Bill Herrin
> 
> 
> 

Re: Introducing draft-denog-v6ops-addresspartnaming

[William Herrin]

On Thu, Nov 18, 2010 at 9:07 PM, Richard Hartmann
 wrote:
> as most of you are aware, there is no definite, canonical name for the
> two bytes of IPv6 addresses between colons. This forces people to use
> a description like I just did instead of a single, specific term.

Hi Richard,

I have an anti-naming proposal: Allow users to place the colons
-anywhere- or even leave them out altogether without changing the
semantics of the IPv6 address.

The colons are there for readability purposes only. They have no
special significance and should not be elevated to significance by
naming the parts of the address they delineate. Treat them specially
and some fools will attach importance to arranging tasks on two-byte
boundaries.

The meaningful boundaries in the protocol itself are nibble and /64.
If you want socially significant boundaries, add /12, /32 and /48.

Regards,
Bill Herrin



-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Blocking International DNS

[Marshall Eubanks]

It seems that the Combating Online Infringement and Counterfeits Act (COICA) 
passed through the Senate Judiciary Committee 
with a unanimous (!) vote :

http://arstechnica.com/tech-policy/news/2010/11/pirate-slaying-censorship-bill-gets-unanimous-support.ars

http://www.govtrack.us/congress/billtext.xpd?bill=s111-3804

I claim operational content for this as, on the basis of court orders, i..e. a

"temporary restraining order, a preliminary injunction, or an injunction 
against the domain name used by an Internet site dedicated to infringing 
activities"

it requires that, for foreign domain names,

"(i) a service provider, as that term is defined in section 512(k)(1) of title 
17, United States Code, or other operator of a domain name system server shall 
take reasonable steps that will prevent a domain name from resolving to that 
domain name’s Internet protocol address;"

This expedited DNS cutoff is only available for copyright violations, not for 
other illegalities. 

Whether this has any chance of actually passing through this Lame Duck Congress 
remains to be seen, but my personal reading is that that is not likely. 

Regards
Marshall

Re: IPv6 6to4 and dns

[Franck Martin]

I use HE.NET in a few installations (with BGP) and they have good support 
(which is quite awesome for a free service).

As people pointed out avoid 6to4, Apple just rendered it nearly useless in its 
latest OS-X.

- Original Message -
From: "Jeroen van Aart" 
To: "NANOG list" 
Sent: Saturday, 20 November, 2010 9:07:53 AM
Subject: Re: IPv6 6to4 and dns

Mark Andrews wrote:
> Firstly I would use a tunnel broker instead of 6to4.  Easier to
> debug failures.

Thanks all for the helpful response. Using the same names for IPv6 and 
IPv4 doesn't appear to be much of a problem, especially considering this 
is a trial which concerns office/home ISP connectivity, for now.

Which IPv6 tunnel broker is preferable, or does it really matter?

Thanks,
Jeroen

Re: Introducing draft-denog-v6ops-addresspartnaming

[Joel Jaeggli]

On 11/19/10 10:56 AM, Owen DeLong wrote:
>> It is always two bytes. A byte is not always an octet. Some machines do
> 
> It is always two OCTETS. A byte is not always an octet...

Assuming you have a v6 stack on your cdc6600 a v6 address fits in 22
bytes not 16.

>> have byte sizes other than 8 bits, although few of them are likely to have
>> IPv6 stacks, so, this may be an academic distinction at this point.

One can define that byte size for the purposes of the human reading of
addresses ipv6 as 8 bits, without getting into machine specific details.
what's important to the machine isn't the division of the address into
parts (they aren't divided in the machine representation it's just one
long row of bits) but rather where the mask falls.


>> Owen
>>
> 
> 

Re: IPv6 6to4 and dns

[Jeroen van Aart]

Mark Andrews wrote:

Firstly I would use a tunnel broker instead of 6to4.  Easier to
debug failures.


Thanks all for the helpful response. Using the same names for IPv6 and 
IPv4 doesn't appear to be much of a problem, especially considering this 
is a trial which concerns office/home ISP connectivity, for now.


Which IPv6 tunnel broker is preferable, or does it really matter?

Thanks,
Jeroen

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 20 Nov, 2010

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  337920
Prefixes after maximum aggregation:  153662
Deaggregation factor:  2.20
Unique aggregates announced to Internet: 165745
Total ASes present in the Internet Routing Table: 35314
Prefixes per ASN:  9.57
Origin-only ASes present in the Internet Routing Table:   30423
Origin ASes announcing only one prefix:   14892
Transit ASes present in the Internet Routing Table:4891
Transit-only ASes present in the Internet Routing Table:118
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  31
Max AS path prepend of ASN (36992)   29
Prefixes from unregistered ASNs in the Routing Table:   374
Unregistered ASNs in the Routing Table: 168
Number of 32-bit ASNs allocated by the RIRs:901
Prefixes from 32-bit ASNs in the Routing Table:   4
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:198
Number of addresses announced to Internet:   2301671776
Equivalent to 137 /8s, 48 /16s and 185 /24s
Percentage of available address space announced:   62.1
Percentage of allocated address space announced:   65.4
Percentage of available address space allocated:   95.0
Percentage of address space in use by end-sites:   85.6
Total number of prefixes smaller than registry allocations:  139129

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:82883
Total APNIC prefixes after maximum aggregation:   28130
APNIC Deaggregation factor:2.95
Prefixes being announced from the APNIC address blocks:   79793
Unique aggregates announced from the APNIC address blocks:34792
APNIC Region origin ASes present in the Internet Routing Table:4240
APNIC Prefixes per ASN:   18.82
APNIC Region origin ASes announcing only one prefix:   1191
APNIC Region transit ASes present in the Internet Routing Table:683
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 17
Number of APNIC addresses announced to Internet:  564159264
Equivalent to 33 /8s, 160 /16s and 99 /24s
Percentage of available APNIC address space announced: 76.4

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
   55296-56319, 131072-132095
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  42/8,  43/8,  49/8,
58/8,  59/8,  60/8,  61/8, 101/8, 110/8, 111/8,
   112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8,
   119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8,
   126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:137691
Total ARIN prefixes after maximum aggregation:71142
ARIN Deaggregation factor: 1.94
Prefixes being announced from the ARIN address blocks:   108854
Unique aggregates announced from the ARIN address blocks: 43801
ARIN Region origin ASes present in the Internet Routing Table:14049
ARIN Prefixes per ASN: 7.75
ARIN Region origin ASes announcing only one prefix:5384
ARIN Region transit ASes present in the Internet Routing Table:1492
Average ARIN Region AS path length visible: 4.0
Max ARIN Region AS path length visible:   

Re: Introducing draft-denog-v6ops-addresspartnaming

[Owen DeLong]

On Nov 19, 2010, at 8:58 AM, Owen DeLong wrote:

> 
> On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote:
> 
>> On Fri, Nov 19, 2010 at 07:00,   wrote:
>> 
>>>   problem is, its not alwas ggoig to be two bytes...
>> 
>> It's always two bytes, but people may choose to omit them. That is a
>> social, not a (purely) technical, syntax, though.
> 
Oops... Hit send too fast...

> It is always two bytes. A byte is not always an octet. Some machines do

It is always two OCTETS. A byte is not always an octet...

> have byte sizes other than 8 bits, although few of them are likely to have
> IPv6 stacks, so, this may be an academic distinction at this point.
> 
> Owen
> 

Re: Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2

[Pete Lumbis]

The GRE encap on a software based router like an ISR should be
resolved in CEF from the start, so it shouldn't be two CEF lookups.
However, on the software based platforms, every feature you turn on
takes a little more CPU so even with a single lookup I wouldn't expect
the same performance from GRE that I would from non-GRE traffic.

6k/7600 requires recirculation in hardware and the story is completely
different as you are basically running the packet through the hardware
twice.

-Pete

On Fri, Nov 19, 2010 at 12:28 PM, Michael Ulitskiy  wrote:
> On Thursday 18 November 2010 18:18:04 Sam Chesluk wrote:
>> There are a couple potential issues, that when looked at in whole, add
>> up to a significant performance impact.
>>
>> 1) IPSec + GRE involves two forwarding operations, one to send it to the
>> tunnel interface , and another to send the now-encapsulated packet out
>> the WAN interface.  This effectively halves the total forwarding rate
>> before any other considerations.
>
>> 2) While the IPSec portion is hardware accelerated, the GRE
>> encapsulation is not, unless this is a Cat6500/CISCO7600 router, or
>> 7200VXR with C7200-VSA card.  Because of this, the GRE process itself
>> will consume a fairly large amount of CPU, as this is also a per-packet
>> process.  The impact is similar to a forwarding decision, so that
>> throughput level is halved again.
>
> I would like to question this one.
> I always thought that GRE header is pre-calculated and kept in the CEF 
> adjacency table,
> thus GRE encapsulation involves no additional processing overhead compared to 
> regular ethernet encapsulation.
> The only difference with 6500/7600 is that encapsulation is done by CPU, not 
> PFC.
> I'm in no way an expert in this, but I'd imagine the whole process to be like 
> this:
> 1. a sinlge CEF lookup/encapsulation produces a GRE packet
> 2. packet encryption/ESP encapsulation
> 3. another CEF lookup/encapsulation to get the encrypted packet out
> So forwarding rate halved, but just once.
> Am I wrong?
>
> Michael
>
>

Re: Introducing draft-denog-v6ops-addresspartnaming

[Cutler James R]

I have a quibble with this discussion.  When I defined a "byte" as "a mouthful 
of bits" to my boss back in 1977, he nearly fired me on the spot. He did not 
care about PDP-10 , much less PDP-11, data constructs.

By now, octet has become essentially synonymous with byte and nibble with 
4-bits.  Could we just refer to "n octets"?

Cutler

For Reference Only:
On Nov 19, 2010, at 11:06 AM, Richard Hartmann wrote:

> On Fri, Nov 19, 2010 at 14:14, Scott Morris  wrote:
> 
>> If 8 bits is a byte, then 16 bits should be a mouthful.
> 
> When does it become a meal and, more importantly, do you want to
> supper (sic) size?
> 
> 
> RIchard
> 

James R. Cutler
james.cut...@consultant.com

Re: Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2

[Michael Ulitskiy]

On Thursday 18 November 2010 18:18:04 Sam Chesluk wrote:
> There are a couple potential issues, that when looked at in whole, add
> up to a significant performance impact.
> 
> 1) IPSec + GRE involves two forwarding operations, one to send it to the
> tunnel interface , and another to send the now-encapsulated packet out
> the WAN interface.  This effectively halves the total forwarding rate
> before any other considerations.

> 2) While the IPSec portion is hardware accelerated, the GRE
> encapsulation is not, unless this is a Cat6500/CISCO7600 router, or
> 7200VXR with C7200-VSA card.  Because of this, the GRE process itself
> will consume a fairly large amount of CPU, as this is also a per-packet
> process.  The impact is similar to a forwarding decision, so that
> throughput level is halved again.

I would like to question this one.
I always thought that GRE header is pre-calculated and kept in the CEF 
adjacency table,
thus GRE encapsulation involves no additional processing overhead compared to 
regular ethernet encapsulation. 
The only difference with 6500/7600 is that encapsulation is done by CPU, not 
PFC.
I'm in no way an expert in this, but I'd imagine the whole process to be like 
this:
1. a sinlge CEF lookup/encapsulation produces a GRE packet
2. packet encryption/ESP encapsulation
3. another CEF lookup/encapsulation to get the encrypted packet out
So forwarding rate halved, but just once.
Am I wrong?

Michael

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 17:58, Owen DeLong  wrote:

> It is always two bytes. A byte is not always an octet. Some machines do
> have byte sizes other than 8 bits

Vice versa. It's always two octects, but on some systems it may not be
two bytes.


>, although few of them are likely to have
> IPv6 stacks, so, this may be an academic distinction at this point.

Agreed.


We can revisit this once we all own a few portable quantum computers, though :)

Richard

Re: Introducing draft-denog-v6ops-addresspartnaming

[Jay Nugent]

Greetings,

On Fri, 19 Nov 2010, Owen DeLong wrote:

> >> I'm sorry to quibble with the majority here, but, in this case, I think
> >> we have enough problems with ambiguous terminology in
> >> networking and this opportunity to avoid creating one more should
> >> not be missed.
> > 
> (The above paragraph was mainly so that I had an opportunity to toss
> quibble into the text with it's other meaning).
> 
> > Agreed. OTOH, Hextet is not technically correct while appearing to be so.
> > 
> 
> 
> True... The correct term would be decohextet, but, decohextet is rather
> long both to say and to write and really doesn't roll off the tongue the
> way hextet does.

   I like to call it a "HexNot" - a hexidecimal representation of zeros.

   ::


  --- Jay Nugent

() ascii ribbon campaign in
/\ support of plain text e-mail
 
Train how you will Operate, and you will Operate how you were Trained.
++
| Jay Nugent   j...@nuge.com(734)484-5105(734)649-0850/Cell   |
|   Nugent Telecommunications  [www.nuge.com]|
|   Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring |
| Web-Pegasus[www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
++
 12:01pm  up 72 days, 21:25,  3 users,  load average: 0.15, 0.07, 0.05

Re: Introducing draft-denog-v6ops-addresspartnaming

[Owen DeLong]

On Nov 19, 2010, at 12:57 AM, Richard Hartmann wrote:

> On Fri, Nov 19, 2010 at 07:00,   wrote:
> 
>>problem is, its not alwas ggoig to be two bytes...
> 
> It's always two bytes, but people may choose to omit them. That is a
> social, not a (purely) technical, syntax, though.

It is always two bytes. A byte is not always an octet. Some machines do
have byte sizes other than 8 bits, although few of them are likely to have
IPv6 stacks, so, this may be an academic distinction at this point.

Owen

Re: Introducing draft-denog-v6ops-addresspartnaming

[Owen DeLong]

>> I'm sorry to quibble with the majority here, but, in this case, I think
>> we have enough problems with ambiguous terminology in
>> networking and this opportunity to avoid creating one more should
>> not be missed.
> 
(The above paragraph was mainly so that I had an opportunity to toss
quibble into the text with it's other meaning).

> Agreed. OTOH, Hextet is not technically correct while appearing to be so.
> 


True... The correct term would be decohextet, but, decohextet is rather
long both to say and to write and really doesn't roll off the tongue the
way hextet does.

Owen

Re: Introducing draft-denog-v6ops-addresspartnaming

[William Pitcock]

On Fri, 2010-11-19 at 17:06 +0100, Richard Hartmann wrote:
> On Fri, Nov 19, 2010 at 14:14, Scott Morris  wrote:
> 
> > If 8 bits is a byte, then 16 bits should be a mouthful.
> 
> When does it become a meal and, more importantly, do you want to
> supper (sic) size?
> 

The supersize option offered by e.g. McDonalds is not much larger than
the normal meal size in my experience.

So I guess, 8 bits = small, 16 bits = meal, 24 bits = supersize or
something, but that doesn't fit well with IPv6 since each segment
between colons is only 16 bits.

We could call the :: part the 'liposection' though.

William

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 14:14, Scott Morris  wrote:

> If 8 bits is a byte, then 16 bits should be a mouthful.

When does it become a meal and, more importantly, do you want to
supper (sic) size?


RIchard

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 10:57, George Bonser  wrote:

> That's exactly what I was going to say but didn't want to quibble.  We tend 
> to call them "quads" at work.  What do you call that indeterminate space 
> between two colons :: where it might be four or more zeros in there? That's a 
> bunch of nibbles, maybe a "gulp"?

I don't call it anything. "The fourth $decided_upon is zero/empty" suffices :)

Though if that gap does not have a name yet, I suppose it can't hurt
to try and think of a canonical name, either.


Richard

Re: How many IPv6 prefixes should you have (Was: IPv6)

[Jeroen Massar]

On 2010-11-19 16:35, Antonio Querubin wrote:
> On Fri, 19 Nov 2010, Jeroen Massar wrote:
> 
>> What now is more disturbing is that there appears to be a couple of
>> prefixes out there which are not in the ARIN registry anymore which are
>> still being used (Hexago/Gogo6/Freenet6/nameoftheday's 2001:5c0::/32 is
>> an exemplary one) but also 2001:1890::/32 for AT&T worldservices,
> 
> In whois they're really a /29 but nothing prevents them from advertising
> individual /32 at different points around the net.
> 
> http://whois.arin.net/rest/net/NET6-2001-1890-1

That explains that one at least, as it seems they upgraded themselves
out of a /32 to a /29 on 2010-10-01, seems they didn't come around
actually announcing that space yet though.

Now how shall I make GRH believe that the /32 was there once, being
announced for 7 years, but the /29 isn't yet, as stating the /29 is
announced since then is not right and tossing that information out would
not be entirely correct either...

Same goes for Rackspace it seems who are now a /30, they are at least
announcing the aggregate. Adobe also did a /48 -> /45 upgrade but are
still just announcing their old /48, same for PCH and Tellme.

The Hexago prefix though is completely missing from whois and I am
really wondering what is up with that as that prefix is quite well used
one would think. Hope somebody sorts that one out.


As for the subject of advertising more specifics... what if eg DTAG or
France Telecom decided to start announcing every separate /32 out of
their /19, that would be 8k extra routes each and the world is larger
than that thus those 300k routes in IPv6 can easily be done.

Of course, as there are a couple of RIRs who are doling out multiple
disjunct prefixes to ISPs already and various ISPs are going to all of
the RIRs for a prefix per country in some cases, not much that can be
done about that kind of swamping I guess. thus better start coming
up with some good hardware folks that can handle copious amounts of very
long routes ;)

Greets,
 Jeroen

Re: How many IPv6 prefixes should you have (Was: IPv6)

[Antonio Querubin]

On Fri, 19 Nov 2010, Jeroen Massar wrote:


What now is more disturbing is that there appears to be a couple of
prefixes out there which are not in the ARIN registry anymore which are
still being used (Hexago/Gogo6/Freenet6/nameoftheday's 2001:5c0::/32 is
an exemplary one) but also 2001:1890::/32 for AT&T worldservices,


In whois they're really a /29 but nothing prevents them from advertising 
individual /32 at different points around the net.


http://whois.arin.net/rest/net/NET6-2001-1890-1

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  t...@lava.net

Re: Introducing draft-denog-v6ops-addresspartnaming

[David Israel]

On 11/19/2010 4:57 AM, George Bonser wrote:


It's always two bytes, but people may choose to omit them. That is a
social, not a (purely) technical, syntax, though.


Richard

That's exactly what I was going to say but didn't want to quibble.  We tend to call them 
"quads" at work.  What do you call that indeterminate space between two colons :: where 
it might be four or more zeros in there? That's a bunch of nibbles, maybe a "gulp"?



Yeah, I think I'd quibble with quibble; it's antagonistic.  "Gulp" has 
serious potential in casual conversation (especially because you can 
refer to the excluded "::" portion as "the Big Gulp") but somehow I 
don't see it used in technical documentation.  I like "morsel," 
personally.  (Well, I also like "collop," because it's arcane and sounds 
vaguely dirty to me, but I don't think that would catch on.)

Re: Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2

[Christopher J. Pilkington]

On Thu, Nov 18, 2010 at 02:47:35PM -0800, Seth Mattinen wrote:
> The ISR series do have onboard hardware crypto, but I don't know offhand
> if it can handle a full DS3 worth.
> 
> My first guess is fragment reassembly would probably kill it fast.

We're not seeing fragmentation. The MTU of the physical DS3 is
arbitrarily large (over 9000) to intentionally avoid this.

-cjp

Re: Cisco GRE/IPSec performance, 3845 ISR/3945 ISR G2

[Christopher J. Pilkington]

On Thu, Nov 18, 2010 at 03:18:04PM -0800, Sam Chesluk wrote:
> 2) While the IPSec portion is hardware accelerated, the GRE
> encapsulation is not, unless this is a Cat6500/CISCO7600 router, or
> 7200VXR with C7200-VSA card.  Because of this, the GRE process itself
> will consume a fairly large amount of CPU, as this is also a per-packet
> process.  The impact is similar to a forwarding decision, so that
> throughput level is halved again.

I think this is where we're having the issue. It is just
shocking that this is occurring in a relatively low kpps
situation.

> 3) Other factors like quantity of tunnels, any routing protocols
> running, NAT, or other such control protocols all have their own CPU
> demands too, and can, in aggregate, be a small but significant burden
> when the router also has to handle the demands of IPSec + GRE.

The number we were given for the 3945 for IMIX 1400 raw IPSec
performance was 840Mbps.  However, all this extra crypto power
is completely useless if the GRE processing is hitting the same
limits as it's predecessor, the 3845.

We're going to give straight IPSec a go to see if that solves
things.

-cjp

Re: Introducing draft-denog-v6ops-addresspartnaming

[Scott Morris]

If 8 bits is a byte, then 16 bits should be a mouthful.

;)

Scott

On 11/18/10 10:45 PM, George Bonser wrote:
>
>> Hi all,
>>
>>
>> as most of you are aware, there is no definite, canonical name for the
>> two bytes of IPv6 addresses between colons. This forces people to use
>> a description like I just did instead of a single, specific term.
>>
> I am ok with "quibble" but I don't think it will gain wide usage in the US.  
> We use "quad" at work.
>
> G
>

How many IPv6 prefixes should you have (Was: IPv6)

[Jeroen Massar]

Job Snijders wrote:
> They are missing roughly 1000 prefixes. 

See http://www.sixxs.net/tools/grh/status/

which just now when I peeked stated at the top:
8<-
2704 good/required prefixes
Minimum of 1714 prefixes (-990)
Average of 3513 prefixes (+809)
Maximum of 3861 prefixes (+1157)
186 peers, 67 not connected
->8

As such, a proper transit should be delivering you with 2704 prefixes
for it to make you able to reach every place that should be reachable.

Some organisations send upwards of 1157 *MORE* prefixes than necessary,
note that is almost 30% more, thus junk prefixes which you don't need,
guess where a lot of those junk prefixes come from...

GRH doesn't have data on Cogent unfortunately (maybe check RIS?).

L(3) at the moment misses 632 prefixes that they should have:
http://www.sixxs.net/tools/grh/dfp/all/?missing=3356

For everyone's 'but another "transit" has more prefixes excuse, they
don't get all the prefixes either, they are missing 178 of them:
http://www.sixxs.net/tools/grh/dfp/all/?missing=6939

Though I have to note, for both the latter two cases that quite a few of
those prefixes are marked orange and thus those prefixes are only seen
by a small majority of the folks who send prefixes to GRH anyway.


What now is more disturbing is that there appears to be a couple of
prefixes out there which are not in the ARIN registry anymore which are
still being used (Hexago/Gogo6/Freenet6/nameoftheday's 2001:5c0::/32 is
an exemplary one) but also 2001:1890::/32 for AT&T worldservices,
2001:4800::/32 which once was Rackspace and quite a few others...

It just shows that everybody is just letting IPv6 routing grow as a
swamp till the real transits move in and start filtering nicely to get
the weed sorted out.

Btw RPSL anyone? You do know that nowadays the RIPE IRR allows ARIN
prefixes to be properly authenticated and registered too I hope?

See for more information:
http://labs.ripe.net/Members/Paul_P_/ripe-registry-global-resource-service

Please use this facility, kthx!

Greets,
 Jeroen

Re: IPv6

[sthaug]

> > That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
> > So cogent IPv6 Customers currently can not hit things at HE. And they can't 
> > do anything about it. Besides 6to4 tunneling and BGP peering with HE (or 
> > native, If they can).
> 
> A few weeks ago I compared what cogent sees compared to a tata+highwinds 
> feed. 
> 
> http://blog.snijders-it.nl/2010/10/cogent-as174-does-not-have-full-ipv6.html
> 
> They are missing roughly 1000 prefixes. 

As long as we are in public "naming and shaming" mode, it should be noted
that Cogent is not alone. We have an IPv4/IPv6 transit from Level3, and
they don't have the HE prefixes either.

Our two other IPv4/IPv6 transits seem to have no problem supplying us with
a full IPv6 routing table.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: IPv6

[Jeroen Wunnink]

I second that, we're only getting ~2665 IPv6 prefixes from Cogent 
compared to the ~3650 from our other transits. (been like that for more 
then a year now)


Cogent's stance on it is 'You're multihomed with other transits, so 
you're still reachable anyways' which strikes me as very odd for someone 
who's supposed to be selling global transit.
They once called me asking about how satisfied we were with their IPv6 
transit, but quickly ended the conversation once I asked about the 
incomplete feed and the HE peering refusal.


Personally we don't see Cogent as a serious transit provider for IPv6 
and have their v6 prefixes set with a very low priority.




On 11/19/10 12:35 PM, Job W. J. Snijders wrote:

Hello,

On 19 nov 2010, at 00:00, Nick Olsen wrote:

   

That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
So cogent IPv6 Customers currently can not hit things at HE. And they can't
do anything about it. Besides 6to4 tunneling and BGP peering with HE (or
native, If they can).
 

A few weeks ago I compared what cogent sees compared to a tata+highwinds feed.

http://blog.snijders-it.nl/2010/10/cogent-as174-does-not-have-full-ipv6.html

They are missing roughly 1000 prefixes.

Kind regards,

Job Snijders
   


--

Met vriendelijke groet,

Jeroen Wunnink,
EasyHosting B.V. Systeembeheerder
systeembeh...@easyhosting.nl

telefoon:+31 (035) 6285455  Postbus 48
fax: +31 (035) 6838242  3755 ZG Eemnes

http://www.easyhosting.nl
http://www.easycolocate.nl

Re: IPv6

[Job W. J. Snijders]

Hello,

On 19 nov 2010, at 00:00, Nick Olsen wrote:

> That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
> So cogent IPv6 Customers currently can not hit things at HE. And they can't 
> do anything about it. Besides 6to4 tunneling and BGP peering with HE (or 
> native, If they can).

A few weeks ago I compared what cogent sees compared to a tata+highwinds feed. 

http://blog.snijders-it.nl/2010/10/cogent-as174-does-not-have-full-ipv6.html

They are missing roughly 1000 prefixes. 

Kind regards,

Job Snijders

RE: Introducing draft-denog-v6ops-addresspartnaming

[George Bonser]

> On Fri, Nov 19, 2010 at 07:00,   wrote:
> 
> >        problem is, its not alwas ggoig to be two bytes...
> 
> It's always two bytes, but people may choose to omit them. That is a
> social, not a (purely) technical, syntax, though.
> 
> 
> Richard

That's exactly what I was going to say but didn't want to quibble.  We tend to 
call them "quads" at work.  What do you call that indeterminate space between 
two colons :: where it might be four or more zeros in there? That's a bunch of 
nibbles, maybe a "gulp"?

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 09:09, Frank Habicht  wrote:

> I saw 'field' somewhere
>
> http://tools.ietf.org/html/rfc5952#section-2.1
> seems to agree.

I seem to remember "field" being used with the understanding that it's
a placeholder and not a definite term. As I can't find an actual
source for that, I will have to get back to you once I found it.


Richard

Re: IPv6

[Owen DeLong]

Another option is a static BGP tunnel with HE which can be configured
at http://tunnelbroker.net. It's not ideal and only useful for relatively low
bandwidth. If your needs are greater, we would much rather sell
you transit or peer with you as appropriate. As everyone should know
by now, we have an aggressively open peering policy.

Feel free to direct questions to me off list or to peer...@he.net
if you have a peering request.

Owen

On Nov 18, 2010, at 3:00 PM, Nick Olsen wrote:

> That's what I'm hearing. Cogent refuses to peer with HE via IPv6.
> So cogent IPv6 Customers currently can not hit things at HE. And they can't 
> do anything about it. Besides 6to4 tunneling and BGP peering with HE (or 
> native, If they can).
> 
> Nick Olsen
> Network Operations
> (855) FLSPEED  x106
> 
> 
> 
> From: "Mike Tancsa" 
> Sent: Thursday, November 18, 2010 5:45 PM
> To: "Lee Riemer" 
> Subject: Re: IPv6
> 
> On 11/18/2010 5:14 PM, Lee Riemer wrote:
>> Try tracerouting to 2001:500:4:13::81 (www.arin.net) or 
>> 2001:470:0:76::2 (www.he.net) via Cogent.
>> 
> 
> Interesting. I noticed a similar issue with  ipv6.cnn.com today. I dont
> see it via TATA, but see it via Cogent.  So whats the story behind it
> and ARIN not being seen through cogent ?  Is it due to no v6 relation
> bewtween he.net and Cogent ?
> 
> 2620:0:2200:8::::8901  (whats with the crazy 8s?)
> 
> see
> http://lg.as6453.net/lg/
> 
> Router: gin-mtt-mcore3
> Site: CA, Montreal - MTT, TATA COMM. INT. CENTER
> Command: traceroute ipv6 2620:0:2200:8::::8901
> 
> Tracing the route to 2620:0:2200:8::::8901
> 
> 1  *  *  *
> 2  *  *  *
> 3  *  *  *
> 4  *  *  *
> 
> ---Mike
> 

Re: Why is your company treating IPv6 turn ups as a sales matter?

[Robert E. Seastrom]

"George, Wes E [NTK]"  writes:

> > Sprint and Qwest, I know you're guilty.
>
> Bill, I know that you mean well and you're just trying to push IPv6
> deployment, and sometimes a little public shame goes a long way, but in the
> future, before you call my company out in public with tenuous assertions
> like this, please at least try to reach out to me privately to address your
> perceived issue with the way Sprint is handling IPv6 rollout? It's not like
> I'm hard to find, even if it's a blast message to NANOG that looks like
> "Will someone with IPv6 clue at Sprint contact me?"

I totally sympathize with the "please don't bash us in public"
sentiment, but "holler on NANOG" does not scale.  If the intent is to
be selling IPv6 to the great unwashed masses (a laudable goal if you
want to continue to grow post-v4-runout), it's got to be no more
difficult than getting IPv4.  Needs to be productized in such a way
that the default case is that you get both, and if you don't turn on
the v6, well, shame on you.

-r

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 08:42, Owen DeLong  wrote:

> Since the poll is a straight yes/no option with no preference, I will
> express my preference here.

I considered using the Condorcet method [1] (modified for NotA), but
as past experience has shown that people get easily confused by it, I
decided to create a "plain" poll, instead.


> While I find the term quibble fun and
> amusing, I think hextet is a far more useful term because it does not
> have the overloaded human semantics that come with quibble.

To be completely honest, while I did know the term, I had forgotten
about it. This is part of the reason why I am seeking a wider
audience. I'll add this consideration to the draft. I agree that this
might be (not has to be) a deal breaker.


> I'm sorry to quibble with the majority here, but, in this case, I think
> we have enough problems with ambiguous terminology in
> networking and this opportunity to avoid creating one more should
> not be missed.

Agreed. OTOH, Hextet is not technically correct while appearing to be so.


Thanks a lot,
Richard

[1] http://en.wikipedia.org/wiki/Condorcet_method

Re: Why is your company treating IPv6 turn ups as a sales matter?

[Jay Hennigan]

On 11/18/10 2:24 PM, George, Wes E [NTK] wrote:

> [WES] Because in most companies, sales owns the direct relationship with the
> customer, so when they ask about a new feature or service, they work with
> sales, and sales gets the right technical folks involved. A clarification
> that is probably important here: "a sales matter" != "extra charges for
> IPv6" at least at my employer,...

And therein lies the problem.  By punting technical provisioning tasks
to sales, if it is != "extra charges", you're virtually guaranteeing
that the sales people won't put any effort into making it happen.

Salespeople are driven by commissions (carrot) and quotas (stick).  When
salespeople have to divide their time between tasks that don't
contribute to commission or quota and those that do, guess which gets
done first and which last.

I'm not pointing fingers at Sprint or Wes.  This is a generic problem.
We've been guilty of it too from time to time.  If it's a matter of data
entry or filling out a form, have a secretary do it or make the form
available online.

--
Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV

Re: Introducing draft-denog-v6ops-addresspartnaming

[Richard Hartmann]

On Fri, Nov 19, 2010 at 07:00,   wrote:

>        problem is, its not alwas ggoig to be two bytes...

It's always two bytes, but people may choose to omit them. That is a
social, not a (purely) technical, syntax, though.


Richard

Re: Why is your company treating IPv6 turn ups as a sales matter?

[Pierfrancesco Caci]

:-> "William" == William Herrin  writes:

> Hiya folks,
> Why are your respective companies treating IPv6 turn ups as a sales
> matter instead of a standard technical change request like IP
> addresses or BGP? Sprint and Qwest, I know you're guilty. How many of
> the rest of you are making IPv6 installation harder for your customers
> than it needs to be?


For us, SLAs are not guaranteed for IPv6 yet, hence we want customers to
acknowledge that. This is bound to change sometime in the near future
of course. 



Pf



-- 


---
 Pierfrancesco Caci | Network & System Administrator - INOC-DBA: 6762*PFC
 p.c...@seabone.net | Telecom Italia Sparkle - http://etabeta.noc.seabone.net/

Re: experience with equinix exchange

[Robert E. Seastrom]

Paul is pretty clueful; I think he was asking for specifics as to what
the layer 8/9 issues are at Equinix, rather than an explanation of
what layer 8 and 9 means.

"Fly Fast",

-r


Justin Horstman  writes:

> 8 users
> 9 politics and policies
>
>> -Original Message-
>> From: Paul WALL [mailto:pauldotw...@gmail.com]
>> Sent: Thursday, November 18, 2010 10:55 AM
>> To: Mehmet Akcin
>> Cc: nanog@nanog.org
>> Subject: Re: experience with equinix exchange
>> 
>> What are the layer 8-9 issues?
>> 
>> Drive Slow,
>> Paul Wall
>> 
>> On Thu, Nov 18, 2010 at 12:50 AM, Mehmet Akcin 
>> wrote:
>> >
>> > On Nov 18, 2010, at 12:48 PM, Shacolby Jackson wrote:
>> >
>> >> Has anyone had any experience (good or bad) with their exchange at
>> any of
>> >> their major datacenters, especially Great Oaks? We're wondering if
>> people
>> >> really love or hate it.
>> >>
>> >> -shac
>> >
>> >
>> > Equinix does a fair job running 7 layers , however the layer8 and
>> layer9 seem the lacking part
>> > which could have been improved greatly. in Great Oaks / SJC , they
>> seem to be the largest IX
>> >
>> > per
>> >
>> >
>> https://www.peeringdb.com/private/exchange_view.php?id=5&peerParticipan
>> tsPublicsOrder=Sorter_policy&peerParticipantsPublicsDir=DESC
>> >
>> > so being there while you are in that location seems good, and they
>> are reliable.
>> >
>> > mehmet
>> >

Re: Introducing draft-denog-v6ops-addresspartnaming

[Frank Habicht]

I saw 'field' somewhere

http://tools.ietf.org/html/rfc5952#section-2.1
seems to agree.

Frank

On 11/19/2010 10:42 AM, Owen DeLong wrote:
> Since the poll is a straight yes/no option with no preference, I will
> express my preference here. While I find the term quibble fun and
> amusing, I think hextet is a far more useful term because it does not
> have the overloaded human semantics that come with quibble.
> 
> I'm sorry to quibble with the majority here, but, in this case, I think
> we have enough problems with ambiguous terminology in
> networking and this opportunity to avoid creating one more should
> not be missed.
> 
> Owen
> 
> On Nov 18, 2010, at 6:07 PM, Richard Hartmann wrote:
> 
>> Hi all,
>>
>>
>> as most of you are aware, there is no definite, canonical name for the
>> two bytes of IPv6 addresses between colons. This forces people to use
>> a description like I just did instead of a single, specific term.
>>
>> Being highly pedantic Germans, this annoyed quite a few people within
>> the DENOG community. This, in turn, lead to an I-D[1]. If any of you
>> have any additional suggestions, you are more than  welcome to share
>> them. Additionally, I want to invite everyone to participate in an
>> informal poll which we created[2]. We're fully aware that it's trivial
>> to cheat on this poll; that's life.
>>
>> As of right now, Quibble leads with Hextet being a close second. All
>> other options got significantly less votes.
>>
>>
>> Thanks,
>> Richard
>>
>> [1] http://tools.ietf.org/html/draft-denog-v6ops-addresspartnaming
>> [2] http://doodle.com/5q9gfvk4qe6zmzc6
> 
>