Re: Questions about anycasting setup

[Elmar K. Bins]

Bill,

wo...@pch.net (Bill Woodcock) wrote:

> >   2. We plan to use this anycasting based setup for DNS during initial few
> >   months. Assuming low traffic for DNS say ~10Mbps on average (on 100Mbps
> >   port) and transit from just single network (datacenter itself) - is this
> >   setup OK for simple software based BGP like Quagga or Bird? 
> 
> Yes, and in fact, that's how nearly all large production anycast networks are 
> built???  Each anycast instance contains its own BGP speaker, which announces 
> its service prefix to adjacent BGP-speaking routers, whether those be your 
> own, or your transit-provider's.  Doing exactly as you describe is, in fact, 
> best-practice.

Well, let's say, using Quagga/BIRD might not really be best practice for
everybody... (e.g., *we* are using Cisco equipment for this)

Using anycasting for DNS is, to my knowledge, best practice nowadays.


> >   3. IPv6! - Is /32 is standard? We have only one /32
> >   allocation from ARIN and thus if using /32 seems like hard deal - we have
> >   to likely get another /32 just for anycasting? or we can use /48 without
> >   issues? Also, is /48 a good number for breaking /32 so that we can do /48
> >   announcements from different datacenters in simple uni casting setup?
> 
> A /48 is quite reasonable.  Announcing a whole /32 just for your anycast 
> service would be wasteful.

Why? It's simply another prefix, no matter how big. It might look
wasteful, but if *that* is the allocation you *have*, it's the
one you ought to use.

One should be careful - people do filter on allocation lengths, so
breaking out a /48 out of a /32 allocation and advertising it on its
own can lead to it being filtered.

Elmar.

Re: Questions about anycasting setup

[Mehmet Akcin]

On Mar 9, 2012, at 12:11 AM, Elmar K. Bins wrote:

>>>  3. IPv6! - Is /32 is standard? We have only one /32
>>>  allocation from ARIN and thus if using /32 seems like hard deal - we have
>>>  to likely get another /32 just for anycasting? or we can use /48 without
>>>  issues? Also, is /48 a good number for breaking /32 so that we can do /48
>>>  announcements from different datacenters in simple uni casting setup?
>> 
>> A /48 is quite reasonable.  Announcing a whole /32 just for your anycast 
>> service would be wasteful.
> 
> Why? It's simply another prefix, no matter how big. It might look
> wasteful, but if *that* is the allocation you *have*, it's the
> one you ought to use.
> 
> One should be careful - people do filter on allocation lengths, so
> breaking out a /48 out of a /32 allocation and advertising it on its
> own can lead to it being filtered.

if you know anyone who is filtering /48 , you can start telling them to STOP 
doing so as a good citizen of internet6.

I agree with Woody anything more than /48 for anycast is waste.

mehmet

Re: Questions about anycasting setup

[Pete Carah]

On 03/09/2012 12:11 AM, Elmar K. Bins wrote:
> Bill,
>
> wo...@pch.net (Bill Woodcock) wrote:
>
>>>   2. We plan to use this anycasting based setup for DNS during initial few
>>>   months. Assuming low traffic for DNS say ~10Mbps on average (on 100Mbps
>>>   port) and transit from just single network (datacenter itself) - is this
>>>   setup OK for simple software based BGP like Quagga or Bird? 
>> Yes, and in fact, that's how nearly all large production anycast networks 
>> are built???  Each anycast instance contains its own BGP speaker, which 
>> announces its service prefix to adjacent BGP-speaking routers, whether those 
>> be your own, or your transit-provider's.  Doing exactly as you describe is, 
>> in fact, best-practice.
> Well, let's say, using Quagga/BIRD might not really be best practice for
> everybody... (e.g., *we* are using Cisco equipment for this)
Actually there is a *very* good reason why many (most?) anycast
instances use quagga/BIRD/gated/etc
to speak bgp (or even ospf for internal anycast) which using a Cisco (or
any separate router) usually won't accomplish.

-- Pete

>
> Using anycasting for DNS is, to my knowledge, best practice nowadays.
>
>

filtering /48 is going to be necessary

[Jeff Wheeler]

On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin  wrote:
> if you know anyone who is filtering /48 , you can start telling them to STOP 
> doing so as a good citizen of internet6.

I had a bit of off-list discussion about this topic, and I was not
going to bring it up today on-list, but since the other point of view
is already there, I may as well.

Unless you are going to pay the bill for my clients to upgrade their
3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
to do two things before IPv6 up-take is really broad:

1) absolutely must drop /48 de-aggregates from ISP blocks
2) absolutely must make RIR policy so orgs can get /48s for
anycasting, and whatever other purposes

If we fail to adjust RIR policy to account for the huge amount of
accidental de-aggregation that can (and will) happen with IPv6, we
will eventually have to do #1 anyway, but a bunch of networks will
have to renumber in order take advantage of #2 down the road.

The way we are headed right now, it is likely that the IPv6 address
space being issued today will look like "the swamp" in a few short
years, and we will regret repeating this obvious mistake.

We had this discussion on the list exactly a year ago.  At that time,
the average IPv6 origin ASN was announcing 1.43 routes.  That figure
today is 1.57 routes per origin ASN.

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Questions about anycasting setup

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Mar 9, 2012, at 12:11 AM, Elmar K. Bins wrote:
> Well, let's say, using Quagga/BIRD might not really be best practice for
> everybody... (e.g., *we* are using Cisco equipment for this)

How does your Cisco know whether an adjacent nameserver is heavily loaded, and 
adjust its BGP announcements accordingly?

-Bill




-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJPWcigAAoJEG+kcEsoi3+HTy0QAJlt5Sy/uDKFL+JY8ebMReYC
DA5bmtu/mPCzoi9dCQYmm5SeGaPAPE+1idmQE2iXJ8j/MeE+2W13jnna9aQQQuGi
z1P9ZX98gSoJ1CcwOuNQ79wO+Uzi6vGnFMa1sjAP4ZhxsgOUXRqyWAv0VM0JFJCT
yW8vfoK2DpTD2E9zTntRJ4139jSxNr6lQjo5AqwjWeqbKxT2CfHZmX040dAe/nJd
LTWyXnPn7HxYbUVMitYZ4hYD99VVdT3Pq9ufOUGMHgDECxGlXoJ3Ynrif80Pk0iT
QtyU7Rk6kufBT5sFYkjysyzfhWxNtPD34bjz5sj9tMQ4rwb+KgtEHWOiIkUs0ET3
ZqiZOy6n3ecLq+IkayO/37vol9LdLdev3nNBE3sOrFZITnR/39wAaT/7x5yusU+N
NbEXAum4WJt8pIbpkyxCTBFMXxJ0MhNYvMRhqbm/1SCtvC5Dw6mPLIZnYG0UEn8j
0jyEVQ3jJz+l6ID0FBgXZVdCMMcafpCnm+A50xOd1Gsw+5ojqWqJ/Lqd7Rp4XcgD
FJejwt4Qtu+L5q8LMu96R9ohGg8Uqx9CBz3qDAB9X7Xipx3bWYFlDJM5Pf832VH5
3W0GZKGCqWmtHWBmzZAJNTySKsHYfStqzVMnwXDsPBQGm2ScKS44t+v56FGcHu29
izRP8sni+zNBKsTB5x2h
=Ltey
-END PGP SIGNATURE-

Re: filtering /48 is going to be necessary

[Jeroen Massar]

On 2012-03-09 10:02 , Jeff Wheeler wrote:
> On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin  wrote:
>> if you know anyone who is filtering /48 , you can start telling them to STOP 
>> doing so as a good citizen of internet6.
> 
> I had a bit of off-list discussion about this topic, and I was not
> going to bring it up today on-list, but since the other point of view
> is already there, I may as well.
> 
> Unless you are going to pay the bill for my clients to upgrade their
> 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
> to do two things before IPv6 up-take is really broad:
> 
> 1) absolutely must drop /48 de-aggregates from ISP blocks

See the strict filter at:
 http://www.space.net/~gert/RIPE/ipv6-filters.html

which has been proposed for quite a long time already.

Also note the existence of this awesome thing called RPSL.

See also this great presentation by ras:
http://www.nanog.org/meetings/nanog44/presentations/Tuesday/RAS_irrdata_N44.pdf

and the very recent column by Geoff Huston:
http://www.potaroo.net/ispcol/2012-03/leaks.html

> 2) absolutely must make RIR policy so orgs can get /48s for
> anycasting, and whatever other purposes

One can already receive those easily, generally as a /48.

Also, quite a few organizations are requesting disjunct /32's per
country or at least a /32 per region

Greets,
 Jeroen

Re: Questions about anycasting setup

[Elmar K. Bins]

Re Bill,

p...@altadena.net (Pete Carah) wrote:

> > Well, let's say, using Quagga/BIRD might not really be best practice for
> > everybody... (e.g., *we* are using Cisco equipment for this)
> Actually there is a *very* good reason why many (most?) anycast
> instances use quagga/BIRD/gated/etc
> to speak bgp (or even ospf for internal anycast) which using a Cisco (or
> any separate router) usually won't accomplish.

Please enlighten me...

Elmar.

Re: Questions about anycasting setup

[Elmar K. Bins]

Re Bill,

wo...@pch.net (Bill Woodcock) wrote:

> > Well, let's say, using Quagga/BIRD might not really be best practice for
> > everybody... (e.g., *we* are using Cisco equipment for this)
> How does your Cisco know whether an adjacent nameserver is heavily loaded, 
> and adjust its BGP announcements accordingly?

It doesn't have to.

I don't know how you guys do it, but we take great care to
keep min. 70% overhead capacity during standard operation.

Elmar.

Re: Questions about anycasting setup

[Bill Woodcock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On Mar 9, 2012, at 1:34 AM, Elmar K. Bins wrote:

> Re Bill,
> 
> wo...@pch.net (Bill Woodcock) wrote:
> 
>>> Well, let's say, using Quagga/BIRD might not really be best practice for
>>> everybody... (e.g., *we* are using Cisco equipment for this)
>> How does your Cisco know whether an adjacent nameserver is heavily loaded, 
>> and adjust its BGP announcements accordingly?
> 
> It doesn't have to.
> 
> I don't know how you guys do it, but we take great care to
> keep min. 70% overhead capacity during standard operation.

RFC 2870 section 2.3 suggests 33%.  How us guys do it is 2%-3%, since "standard 
operation" is only the case when nobody's getting DDoSed.  And then we have a 
backup plan, which is to be able to redirect queries away from nodes that are 
overloaded.  And we have backup plans for the backup plans.  But then, we've 
been doing anycast DNS for twenty years now, so we've had some time to develop 
those plans.

I think what you're hearing from other people, though, is that having a backup 
plan is, indeed, best practice.

-Bill




-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJPWdE1AAoJEG+kcEsoi3+H2ZsP/2pkKogGXo2THXS4sMPusDdn
FdsnWZIk2KDfFdwko7o135Uiv6Lkr9SeuBsFtohbq05Odo6BU1U/KBXWcwiWB/2y
umk390F0mgKDx0A0S5TPCwgKFQW+u2ynKCsXGMHIvbn+iTWvBrBaV2XGeF1ukU1H
xWqJcXk42GQA7lnqH7vc8HN+SW8Ill9MZp6vqC9ZnWzQ6VyMzZsPWDWPIddgLIhr
vvS5lLCGUdUzqkw/dKXBaQrj9UpjipfQrHx4rOd2M1ULVXngsU1MWxvKpSh3HZZz
68m7Z8J/120NrJ3kthQg/YQJTBG01CYP5pkBYVfB/X7TaYYvFEOtyO57VNEZXNyr
Km1lkUd/iYrwx/+YCQf4TH7h3hfgvC21lwsp6RRhvGkQcBA8Fs8VPUbrschbcU8f
FilndHewhX4zhCNTBhGoeZOAyACOYYib8JwaUOft2JEC40O3NvPjqWXjhK52gpX0
pAhprGo4oDnDGyM6PmO8b5qDdGRA4hyxZq3NwUj+4PI4Lylq34PUE9T2QQVBfRtT
8pKEOyRHgvrmmiYF8Lsvxc2iAze9SZouNqZ7gy1QJ7aikK6LKMp8GQrtgO52AkKm
+wYpIaOKpbscjuBpKGNu331R0ula02TCy6eB75rnbcEd0oDQu14bKwyea6ORl/dh
yRV2lOxCX4oCYYW1yNHd
=Ushc
-END PGP SIGNATURE-

Re: Questions about anycasting setup

[Pete Carah]

On 03/09/2012 01:34 AM, Elmar K. Bins wrote:
> Re Bill,
>
> wo...@pch.net (Bill Woodcock) wrote:
>
>>> Well, let's say, using Quagga/BIRD might not really be best practice for
>>> everybody... (e.g., *we* are using Cisco equipment for this)
>> How does your Cisco know whether an adjacent nameserver is heavily loaded, 
>> and adjust its BGP announcements accordingly?
> It doesn't have to.
>
> I don't know how you guys do it, but we take great care to
> keep min. 70% overhead capacity during standard operation.
>
My point had to do with resilience in the face of hardware/OS/software
failures in the box providing the
service.  Bill's has more to do with resilience in the face of other
network events (e.g. the upstream for one
of the boxes has a DDOS; you cannot reasonably provide enough excess
capacity to handle that...)  Neither of these is addressed by using a
separate router to announce the server's anycast route.  (unless somehow
the Cisco is providing the anycasted service, which would address my
concern but still not Bill's.)

Also, Bill is probably talking root (or bigger public) servers whose
load comes from "off-site"; the average load characteristics for those
are well known but there can be extremes that would be hard to plan for
(hint - operating at 30% isn't really good enough, probably not 10%
either.  Bill (and the other Bill) have pretty good stats for this that
I've only glanced at...)  And it is easy to see where one of the
extremes might hit only one or two of the anycast instances.  He implies
having the instances talking to each other in background to adjust bgp
announcements to maybe help level things.  Fortunately at least for the
root servers, the redundancy is at two levels and anycast is only one of
them.

-- Pete

[NSG-d] Historian is trolling for memories about the early days of SF and ARPANet. Anybody?

[Eugen Leitl]

Sorry for nonoperational content, but this struck me as
a good place to post this query.

- Forwarded message from Fred Hapgood  -

From: Fred Hapgood 
Date: Thu, 08 Mar 2012 17:18:33 -0500
To: ns...@marshome.org
Subject: [NSG-d] Historian is trolling for memories about the early days of
SF and ARPANet. Anybody?
X-Mailer: MessagingEngine.com Webmail Interface
Reply-To: Nanotechnology Study Group - open discussion 





- Original message -
From: "Christopher Leslie" <[1]cles...@poly.edu>
To: [2]hapg...@pobox.com
Date: Thu, 8 Mar 2012 15:47:39 -0500
Subject: sf-lovers
Dear Mr. Hapgood:

Damien Broderick suggested that I contact you for a project I am
working on. I have become intrigued by a connection between
science fiction and the early days of the ARPAnet. As you may
know, one of the first group distribution lists that was not
directly related to defense research was the mailing list
SF-lovers, which was created in Sept. 1979 at MIT by Richard
Brodie. When Usenet became available, a connection was
established, and the travails of the list after that point are
fairly well documented by Saul Jaffe and others.
Before the Usenet list, however, there is not so much
information. I've been in contact with some researchers about
this, but I am hoping that someone on the list might also
remember the days of the sf-lovers list before Usenet. I've also
heard that there were mailing groups on local computers and BBSs
(bulletin board systems) before there were widely dispersed
e-mail list, which if they were discussing science fiction, I
would love to learn about.
If you have any information to share, or can direct me to someone
who does, I would greatly appreciate it. I am writing a book on
science fiction and I think this list demonstrates an interesting
synergy between science fiction and engineering.

Chris Leslie
Christopher S. Leslie, Ph.D.
Instructor of Media and Technology Studies
Polytechnic Institute of New York University
6 MetroTech Center, RH 213h
Brooklyn, NY 11201
(718) 260-3130

References

1. mailto:cles...@poly.edu
2. mailto:hapg...@pobox.com




http://www.BostonScienceLectures.com
http://www.pobox.com/~fhapgood



** The following attachments were removed: multipart/alternative
  text/html

___
Nanotechnology Study Group NSG-d open discussion group
http://www.marshome.org/mailman/listinfo/nsg-d
Send replies (no attachments) to:   nsg-d___no-s...@marshome.org
Questions for list admin: nsg-d-owner___no-s...@marshome.org
Archive: http://MarsHome.org/mailman/private/NSG-d
Unsubscribe: nsg-d-unsubscr...@marshome.org
Password or Options or Unsubscribe: http://MarsHome.org/mailman/options/NSG-d
Hosted by CyberTeams.com and Mars Foundation(tm), http://MarsHome.org

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl http://leitl.org
__
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

Re: filtering /48 is going to be necessary

[William Herrin]

On Fri, Mar 9, 2012 at 4:02 AM, Jeff Wheeler  wrote:
> On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin  wrote:
>> if you know anyone who is filtering /48 , you can
>> start telling them to STOP doing so as a good citizen of internet6.
>
> I had a bit of off-list discussion about this topic, and I was not
> going to bring it up today on-list, but since the other point of view
> is already there, I may as well.
>
> Unless you are going to pay the bill for my clients to upgrade their
> 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
> to do two things before IPv6 up-take is really broad:
>
> 1) absolutely must drop /48 de-aggregates from ISP blocks
> 2) absolutely must make RIR policy so orgs can get /48s for
> anycasting, and whatever other purposes
>
> If we fail to adjust RIR policy to account for the huge amount of
> accidental de-aggregation that can (and will) happen with IPv6, we
> will eventually have to do #1 anyway, but a bunch of networks will
> have to renumber in order take advantage of #2 down the road.

Hi Jeff,

We could use smarter prefix filtering than that. Which was proposed to
ARIN a couple years ago. And failed.

http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html

Regards,
Bill Herrin


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

Re: Request to lease IP space, or things that make you want to go hmmmmm..

[Eric Brunner-Williams]

Thank you George. Not SMTP but HTTP.

I expect exact match string (as brand) marketers, and also
partial match string (as brand typo-squatter) marketers, to exploit
this asset class ("widely spread and legitimately routed IPs").

#include 
#include 
#include 

Eric

Re: filtering /48 is going to be necessary

[Bernhard Schmidt]

Jeff Wheeler  wrote:

Hello Jeff,

> On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin  wrote:
>> if you know anyone who is filtering /48 , you can start telling them
>> to STOP doing so as a good citizen of internet6.
>
> I had a bit of off-list discussion about this topic, and I was not
> going to bring it up today on-list, but since the other point of view
> is already there, I may as well.
>
> Unless you are going to pay the bill for my clients to upgrade their
> 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
> to do two things before IPv6 up-take is really broad:
>
> 1) absolutely must drop /48 de-aggregates from ISP blocks
> 2) absolutely must make RIR policy so orgs can get /48s for
> anycasting, and whatever other purposes

I used to be (or still am) on the same page as you are. I was dropping
everything smaller than a /36 from PA ranges at the edge. 

I recently had to relax this filter, because Cloudflare seems to insist
on throwing tons of /48s from their 2400:cb00::/32 into the air without
an aggregate. And guess what the popular cloud reverse proxy for IPv6
webpages is these days ... cloudflare.

Yes, it sucks, yes, I wrote them, but no answer and no change.

Best Regards,
Bernhard

RE: Request to lease IP space, or things that make you want to go hmmmmm..

[Jim Gonzalez]

-Original Message-
From: George Michaelson [mailto:g...@apnic.net] 
Sent: Thursday, March 08, 2012 8:06 PM
To: NANOG
Subject: Re: Request to lease IP space, or things that make you want to go
hm..


no. you misunderstand.

The value proposition is not spam: that works with unallocated space.

The value proposition is gaming google page rank, by using widely spread and
legitimately routed IPs to force your paying customers page rank high, by
hits and references. This is a very high value business: one customer paying
you big bucks, to have their web high in google pagerank. Not attacking a
million mailboxes.

In this model, the 'target' is google. The IPS need to come from classic,
widespread IPs because google now count the source IP and can tell if you
use a virtually hosted single IP to try and do this.

I have a question: are we actually able to state this consumption of address
is 'illegal' ? I personally judge it to be unethical, but that is not the
same thing.

-George

PS since this goes to address policy, I need to declare that I work for an
RIR but I am posting in a personal capacity and nothing I say is a
reflection of any RIR address policy. I work in the research department, not
in registry/allocations



George,
I would figure Google would check AS path / BGP announcements ? If
they are checking source address why not routing too ?


-Jim

Re: filtering /48 is going to be necessary

[PC]

I think ARIN issues /48s for Provider independent space as the minimum
allocation size, so I'm guessing we shouldn't filter below that.  At least,
that's what's in their current policies.

On Fri, Mar 9, 2012 at 7:50 AM, Bernhard Schmidt wrote:

> Jeff Wheeler  wrote:
>
> Hello Jeff,
>
> > On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin  wrote:
> >> if you know anyone who is filtering /48 , you can start telling them
> >> to STOP doing so as a good citizen of internet6.
> >
> > I had a bit of off-list discussion about this topic, and I was not
> > going to bring it up today on-list, but since the other point of view
> > is already there, I may as well.
> >
> > Unless you are going to pay the bill for my clients to upgrade their
> > 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
> > to do two things before IPv6 up-take is really broad:
> >
> > 1) absolutely must drop /48 de-aggregates from ISP blocks
> > 2) absolutely must make RIR policy so orgs can get /48s for
> > anycasting, and whatever other purposes
>
> I used to be (or still am) on the same page as you are. I was dropping
> everything smaller than a /36 from PA ranges at the edge.
>
> I recently had to relax this filter, because Cloudflare seems to insist
> on throwing tons of /48s from their 2400:cb00::/32 into the air without
> an aggregate. And guess what the popular cloud reverse proxy for IPv6
> webpages is these days ... cloudflare.
>
> Yes, it sucks, yes, I wrote them, but no answer and no change.
>
> Best Regards,
> Bernhard
>
>
>

Re: filtering /48 is going to be necessary

[Bernhard Schmidt]

On 09.03.2012 17:04, PC wrote:

I think ARIN issues /48s for Provider independent space as the
minimum allocation size, so I'm guessing we shouldn't filter below
that.  At least, that's what's in their current policies.


Note that I explicitly wrote:

| I used to be (or still am) on the same page as you are. I was
| dropping everything smaller than a /36 from PA ranges at the edge.
 ^^^

Of course I'm accepting /48 from PI range (in ARIN world 2001:500::/30 
2001:504::/30 and 2620::/23), anything else would be quite brain-dead 
and stupid.


Bernhard

MEF-CECP training

[Andy Susag]

Hi All,

 

It seems like here in the Americas we have a choice of either Tech 2000
or Perpetual Solutions for MEF certification training. Perpetual
Solutions is about $1000 more per seat, but seems a little more robust.
Has anyone gone through this training or used either of these companies?

 

Thanks,

 

Andy Susag

Network Engineer

IFN

 

Re: MEF-CECP training

[david peahi]

I also would be interested in any information. It looks like MEF recognizes
4 training companies:

http://metroethernetforum.org/page_loader.php?p_id=1577

One company offers just 1 class then an exam for certification.

On Fri, Mar 9, 2012 at 9:54 AM, Andy Susag  wrote:

> Hi All,
>
>
>
> It seems like here in the Americas we have a choice of either Tech 2000
> or Perpetual Solutions for MEF certification training. Perpetual
> Solutions is about $1000 more per seat, but seems a little more robust.
> Has anyone gone through this training or used either of these companies?
>
>
>
> Thanks,
>
>
>
> Andy Susag
>
> Network Engineer
>
> IFN
>
>
>
>

UKNOF 22 Call for Presentations

[Mike Hughes]

UKNOF 22 - Call For Presentations

The next UKNOF meeting will take place on Thursday 3rd May 2012
in the City of York, hosted by Bytemark, and the Programme Committee
are seeking content from the community for this meeting.

You may often hear it said that UKNOF's remit is "distribution of
clue", so if the content of your talk fits with that ethos, we're
actually pretty open minded about what the actual topic is - as
long as it's relevant to our community's broad area of interest, and
the quality is good.

Talks are usually around 20 to 40 minutes in length, and common
subject areas are:

* Network operations
* Network architecture and design
* Networking hardware and software architecture
* Peering and interconnect
* Data centre design and operations
* IPv6 deployment
* Network monitoring and measurement
* New innovations in networking technology
* Open protocol standards
* Domain Name System infrastructure
* Network security and abuse prevention
* Impact of public policy of network operations

We are also looking for material relevant to the following topics for York:

* Future Networking Technologies (e.g. 4G/LTE)
* Open Networking Technologies

But, we're always on the lookout for something different, so don't feel it
has to fall into the areas above.

We're also interested in hearing proposals for panel discussions, as
these are a great way of presenting and discussing different views on
the same subject.

Please send your proposals to submissi...@uknof.org.uk, including a
short abstract of the subject, and draft slides if these are
available.

The closing date for submissions is the 5th April 2012, but don't
worry if you miss the deadline and have something interesting to talk
about, as we are often able to accept shorter (10 minute) "lightning
talks" closer in to the meeting.

Please also get in touch if you would like to suggest any topics, themes or
speakers.

Hope to see you in May at the UKNOF meeting.

Mike Hughes on behalf of the UKNOF Programme Committee

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,
TRNOG, 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 10 Mar, 2012

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

Analysis Summary


BGP routing table entries examined:  400226
Prefixes after maximum aggregation:  170764
Deaggregation factor:  2.34
Unique aggregates announced to Internet: 194744
Total ASes present in the Internet Routing Table: 40315
Prefixes per ASN:  9.93
Origin-only ASes present in the Internet Routing Table:   32840
Origin ASes announcing only one prefix:   15490
Transit ASes present in the Internet Routing Table:5414
Transit-only ASes present in the Internet Routing Table:144
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  33
Max AS path prepend of ASN (48687)   24
Prefixes from unregistered ASNs in the Routing Table:   369
Unregistered ASNs in the Routing Table: 162
Number of 32-bit ASNs allocated by the RIRs:   2313
Number of 32-bit ASNs visible in the Routing Table:2061
Prefixes from 32-bit ASNs in the Routing Table:4921
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:561
Number of addresses announced to Internet:   2525381776
Equivalent to 150 /8s, 134 /16s and 68 /24s
Percentage of available address space announced:   68.1
Percentage of allocated address space announced:   68.1
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   92.1
Total number of prefixes smaller than registry allocations:  170161

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:98128
Total APNIC prefixes after maximum aggregation:   31878
APNIC Deaggregation factor:3.08
Prefixes being announced from the APNIC address blocks:   94515
Unique aggregates announced from the APNIC address blocks:39432
APNIC Region origin ASes present in the Internet Routing Table:4670
APNIC Prefixes per ASN:   20.24
APNIC Region origin ASes announcing only one prefix:   1237
APNIC Region transit ASes present in the Internet Routing Table:735
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 18
Number of APNIC region 32-bit ASNs visible in the Routing Table:164
Number of APNIC addresses announced to Internet:  640794208
Equivalent to 38 /8s, 49 /16s and 190 /24s
Percentage of available APNIC address space announced: 81.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/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:149018
Total ARIN prefixes after maximum aggregation:75689
ARIN Deaggregation factor: 1.97
Prefixes being announced from the ARIN address blocks:   120522
Unique aggregates announced from the ARIN address blocks: 49856
ARIN Region origin ASes present in the Internet Routing Table:14928
ARIN Prefixes per ASN: 8.07
ARIN Region origin ASes announcing only one prefix:5667
ARIN 

Whois operational message

[Matt Larson]

This message contains operational information that might be of interest to the 
Internet operational community. Verisign is enabling IPv6 transport for its 
.com/.net Whois service (which also contains information for .edu, .arpa, and 
the root zone).  

By March 31, 2012, Verisign will begin accepting queries to the aforementioned 
Whois service over IPv6 transport in addition to IPv4.  Accordingly, DNS 
queries for the Whois server host names whois.verisign-grs.com, 
whois.verisign-grs.net, whois.crsnic.net, whois.nsiregistry.com, and 
whois.nsiregistry.net will return both A and  records.

If you have any questions or comments, please send email to 
info@verisign‐grs.com or reply to this message.

Matt Larson





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 9, 2012, at 1:02 AM, Jeff Wheeler wrote:

> On Fri, Mar 9, 2012 at 3:23 AM, Mehmet Akcin  wrote:
>> if you know anyone who is filtering /48 , you can start telling them to STOP 
>> doing so as a good citizen of internet6.
> 
> I had a bit of off-list discussion about this topic, and I was not
> going to bring it up today on-list, but since the other point of view
> is already there, I may as well.
> 
> Unless you are going to pay the bill for my clients to upgrade their
> 3BXL/3CXL systems (and similar) to XXL and then XXXL, I think we need
> to do two things before IPv6 up-take is really broad:
> 
> 1) absolutely must drop /48 de-aggregates from ISP blocks
> 2) absolutely must make RIR policy so orgs can get /48s for
> anycasting, and whatever other purposes
> 

Item 1 will be interesting.
Item 2 is already done in ARIN and I think RIPE and APNIC.
I'm not sure about AfriNIC or LACNIC.

> If we fail to adjust RIR policy to account for the huge amount of
> accidental de-aggregation that can (and will) happen with IPv6, we
> will eventually have to do #1 anyway, but a bunch of networks will
> have to renumber in order take advantage of #2 down the road.
> 

Can you point to specific RIR policies that you believe need adjustment?
I'm willing to help (and somewhat adept at doing so), but I'm not seeing
the problem you are reporting, so, I need more data.

> The way we are headed right now, it is likely that the IPv6 address
> space being issued today will look like "the swamp" in a few short
> years, and we will regret repeating this obvious mistake.
> 

I don't think so, actually. First, I don't think the swamp was a mistake so much
as a temporary problem with resource limitation on routers.

The problem in today's routing table is NOT the "swamp". (Where swamp is
defined as the large number of /24s issued to organizations in a non-
aggregable manner often as direct assignments from the InterNIC before
CIDR and provider-assigned addressing existed).

The total scope of the swamp is limited to about 65,000 prefixes.

All of the growth beyond about 65,000 prefixes is, instead, attributable to
a number of other factors, not the least of which are disaggregation for
convenience (which could be  an issue in IPv6), disaggregation due to
ignorance (which will likely be an issue in IPv6), de-aggregation due
to differences in routing policy and/or for traffic management strategies
(which will also happen in IPv6), general growth of the internet (which
will also happen in IPv6, but, at a lower prefix-growth rate), and finally,
one of the biggest causes... slow start, growth constrained RIR policies
handing out incremental (often 1 year worth or less) growth in address
blocks due to scarcity (which should not be a problem in IPv6).

In the ARIN region I think we have pretty well prevented this last issue
with current policy. I tried to propose similar policy in the APNIC region,
but it was not well accepted there. The folks in Asia seem t want to cling
to their scarcity mentality in IPv6 for the time being. I believe RIPE is
issuing reasonably generous IPv6 allocations/assignments. I don't
know enough about the goings on in AfriNIC or LACNIC to comment
with any certainty.

> We had this discussion on the list exactly a year ago.  At that time,
> the average IPv6 origin ASN was announcing 1.43 routes.  That figure
> today is 1.57 routes per origin ASN.

That represents a 10% growth in prefix/asn for IPv6.

Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While
I would agree that this is a trend that merits watching, I think
we're probably OK for quite some time. The higher growth rate in
IPv6 can be largely attributed to the fact that IPv6 is still in its
infancy and we probably haven't seen much IPv6 traffic engineering
route manipulation yet. I don't think IPv6 is at all likely even with
current policies and trends to reach 9:1. I expect it will most likely
settle in somewhere around 2.5:1.

Owen

Re: filtering /48 is going to be necessary

[Owen DeLong]

Let us not forget that there is also the issue of PA /48s being advertised 
(quasi-legitimately) for some end-user organizations that are multi-homed but 
choose not to get PI space. It is not uncommon to obtain a PA /48 from provider 
A and also advertise it from Provider B.

Owen

IPv6 routing table incomplete!

[ML]

Not so shocking for people on this list..However after playing around 
with a single-homed v6 connection to Cogent I was a little surprised to 
not be missing just HE routes.


Apparently Google and Cogent aren't playing nice as I've been unable to 
reach a number of Google's s for ipv6.google.com a quick check for 
paths with _15169_ came up empty.


I figured Cogent and Google would be playing nice by now but apparently 
there is still a rift between these two from May of last year.  At least 
it appears that is when people started noticing weirdness.


Has anyone been documenting who has holes in their BGP tables and to 
where?


P.S

Also don't seen OCCAID from Cogent...maybe Cogent doesn't like tunnel 
brokers??

RE: filtering /48 is going to be necessary

[Leo Vegoda]

Owen wrote:

[...]

> In the ARIN region I think we have pretty well prevented this last issue
> with current policy. I tried to propose similar policy in the APNIC region,
> but it was not well accepted there. The folks in Asia seem t want to cling
> to their scarcity mentality in IPv6 for the time being. I believe RIPE is
> issuing reasonably generous IPv6 allocations/assignments. I don't
> know enough about the goings on in AfriNIC or LACNIC to comment
> with any certainty.

You can see the prefix distribution in charts that are updated daily on our 
stats web site:

http://stats.research.icann.org/

HTH,

Leo

Re: filtering /48 is going to be necessary

[Bernhard Schmidt]

On 09.03.2012 20:31, Owen DeLong wrote:

Hi,


Let us not forget that there is also the issue of PA /48s being
advertised (quasi-legitimately) for some end-user organizations that
are multi-homed but choose not to get PI space. It is not uncommon to
obtain a PA /48 from provider A and also advertise it from Provider
B.


While I agree it's not uncommon, I'm not a big fan of this setup. Also, 
provider A should still have his aggregate announced, which would allow 
strictly filtering ISPs to reach the destination anyway.


Announcing /48s from a PA block without the covering aggregate calls for 
trouble.


Bernhard

Re: IPv6 routing table incomplete!

[David Miller]

On 3/9/2012 3:22 PM, ML wrote:
> Not so shocking for people on this list..However after playing around
> with a single-homed v6 connection to Cogent I was a little surprised
> to not be missing just HE routes.
>
> Apparently Google and Cogent aren't playing nice as I've been unable
> to reach a number of Google's s for ipv6.google.com a quick check
> for paths with _15169_ came up empty.
>
> I figured Cogent and Google would be playing nice by now but
> apparently there is still a rift between these two from May of last
> year.  At least it appears that is when people started noticing
> weirdness.
>
> Has anyone been documenting who has holes in their BGP tables and to
> where?
>
> P.S
>
> Also don't seen OCCAID from Cogent...maybe Cogent doesn't like tunnel
> brokers??
>


http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers

-DMM

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 01-Mar-12 -to- 08-Mar-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS24863   97468  4.4% 116.9 -- LINKdotNET-AS
 2 - AS840258804  2.6%  28.6 -- CORBINA-AS OJSC "Vimpelcom"
 3 - AS982950756  2.3%  50.6 -- BSNL-NIB National Internet 
Backbone
 4 - AS12479   27929  1.2%  52.2 -- UNI2-AS France Telecom Espana SA
 5 - AS24560   25683  1.1%  25.4 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 6 - AS755225635  1.1%  22.0 -- VIETEL-AS-AP Vietel Corporation
 7 - AS32528   22256  1.0%2225.6 -- ABBOTT Abbot Labs
 8 - AS580020192  0.9%  70.6 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 9 - AS55515   17671  0.8% 736.3 -- ONE-NET-HK INTERNET-SOLUTION -HK
10 - AS17974   14673  0.7%   9.8 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
11 - AS20115   14326  0.6%   8.8 -- CHARTER-NET-HKY-NC - Charter 
Communications
12 - AS260914067  0.6% 468.9 -- TN-BB-AS Tunisia BackBone AS
13 - AS28683   13119  0.6% 215.1 -- BENINTELECOM
14 - AS845212500  0.6%   9.9 -- TE-AS TE-AS
15 - AS606612328  0.6%6164.0 -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
16 - AS702911675  0.5%   4.3 -- WINDSTREAM - Windstream 
Communications Inc
17 - AS10620   11029  0.5%   6.2 -- Telmex Colombia S.A.
18 - AS18403   10096  0.5%  19.7 -- FPT-AS-AP The Corporation for 
Financing & Promoting Technology
19 - AS380409510  0.4% 452.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT 
Public Company Limited
20 - AS169609455  0.4%  90.0 -- Cablevision Red, S.A de C.V.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS606612328  0.6%6164.0 -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
 2 - AS32528   22256  1.0%2225.6 -- ABBOTT Abbot Labs
 3 - AS534611160  0.1%1160.0 -- EBTC - Enterprise Bank and 
Trust Company
 4 - AS299333255  0.1%1085.0 -- OFF-CAMPUS-TELECOMMUNICATIONS - 
Off Campus Telecommunications
 5 - AS53362 915  0.0% 915.0 -- MIXIT-AS - Mixit, Inc.
 6 - AS55665 880  0.0% 880.0 -- STMI-AS-ID PT Sampoerna 
Telemedia Indonesia
 7 - AS55515   17671  0.8% 736.3 -- ONE-NET-HK INTERNET-SOLUTION -HK
 8 - AS132771458  0.1% 729.0 -- HP-MS HP-MS Autonomous System
 9 - AS193413096  0.1% 619.2 -- CYENCE-02 - Cyence International
10 - AS36980 469  0.0% 469.0 -- JOHNHOLT-ASN
11 - AS260914067  0.6% 468.9 -- TN-BB-AS Tunisia BackBone AS
12 - AS4 929  0.0%  60.0 -- Maria Irma Salazar
13 - AS380409510  0.4% 452.9 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT 
Public Company Limited
14 - AS532431067  0.1% 355.7 -- 
15 - AS51976 314  0.0% 314.0 -- JP-TELEKOM-AS JP-Telekom Sp. z 
o.o.
16 - AS109866157  0.3% 293.2 -- Intermedia Comunicaciones S.A.
17 - AS38528 284  0.0% 284.0 -- LANIC-AS-AP Lao National 
Internet Committee
18 - AS56886 274  0.0% 274.0 -- REDSTAR-AS OOO "Red Star"
19 - AS36938 264  0.0% 264.0 -- AMSCOTELECOMS Amsco 
Telecommunications Nigeria Limited
20 - AS46904 262  0.0% 262.0 -- WEITZ-LUX - Weitz & Luxenberg 
P.C


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 130.36.34.0/2411121  0.5%   AS32528 -- ABBOTT Abbot Labs
 2 - 130.36.35.0/249  0.5%   AS32528 -- ABBOTT Abbot Labs
 3 - 122.161.0.0/1610382  0.4%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 4 - 182.64.0.0/16 10083  0.4%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 5 - 180.180.250.0/24   9507  0.4%   AS23969 -- TOT-MPLS-VPN-AP TOT Public 
Company Limited
 AS38040 -- GLOBAL-TRANSIT-TOT-IIG-TH TOT 
Public Company Limited
 6 - 62.36.252.0/22 8378  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 7 - 203.28.157.0/246449  0.3%   AS4802  -- ASN-IINET iiNet Limited
 8 - 62.36.249.0/24 6390  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
 9 - 204.29.239.0/246166  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
10 - 150.225.0.0/16 6162  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - 
Verizon Business Network Services Inc.
11 - 62.36.241.0/24 5826  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
12 - 62.36.210.0/24 5615  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 194.63.9.0/24  5382  0.2%   AS1273  -- CW Cable and Wireless

The Cidr Report

[cidr-report]

This report has been generated at Fri Mar  9 21:12:46 2012 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
02-03-12401923  232851
03-03-12401957  232960
04-03-12402003  232914
05-03-12401959  232997
06-03-12402059  233404
07-03-12402370  233534
08-03-12402564  233203
09-03-12402647  233692


AS Summary
 40420  Number of ASes in routing system
 16913  Number of ASes announcing only one prefix
  3459  Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
  111256096  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').

 --- 09Mar12 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 403047   233684   16936342.0%   All ASes

AS6389  3404  201 320394.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS7029  3459 1842 161746.7%   WINDSTREAM - Windstream
   Communications Inc
AS4766  2498 1017 148159.3%   KIXS-AS-KR Korea Telecom
AS22773 1544  120 142492.2%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS2118  1421   14 140799.0%   RELCOM-AS OOO "NPO Relcom"
AS18566 2091  703 138866.4%   COVAD - Covad Communications
   Co.
AS4323  1609  385 122476.1%   TWTC - tw telecom holdings,
   inc.
AS28573 1688  466 122272.4%   NET Servicos de Comunicao S.A.
AS4755  1567  417 115073.4%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS1785  1884  802 108257.4%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS10620 1761  768  99356.4%   Telmex Colombia S.A.
AS7552  1160  203  95782.5%   VIETEL-AS-AP Vietel
   Corporation
AS7303  1324  422  90268.1%   Telecom Argentina S.A.
AS26615  900   30  87096.7%   Tim Celular S.A.
AS8402  1714  854  86050.2%   CORBINA-AS OJSC "Vimpelcom"
AS8151  1487  670  81754.9%   Uninet S.A. de C.V.
AS18101  951  159  79283.3%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS4808  1093  342  75168.7%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS9498   909  228  68174.9%   BBIL-AP BHARTI Airtel Ltd.
AS9394   886  209  67776.4%   CRNET CHINA RAILWAY
   Internet(CRNET)
AS7545  1648  988  66040.0%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS17974 1735 1087  64837.3%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS24560 1005  359  64664.3%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS3356  1106  462  64458.2%   LEVEL3 Level 3 Communications
AS30036 1419  775  64445.4%   MEDIACOM-ENTERPRISE-BUSINESS -
   Mediacom Communications Corp
AS17676  687   75  61289.1%   GIGAINFRA Softbank BB Corp.
AS19262  997  401  59659.8%   VZGNI-TRANSIT - Verizon Online
   LLC
AS15557 1087  499  58854.1%   LDCOMNET Societe Francaise du
   Radiotelephone S.A
AS3549   995  431  56456.7%   GBLX Global Crossing Ltd.
AS22561  951  396  55558.4%   DIGITAL-TELEPORT - Digital
   Teleport Inc.

Total  44980153252965565.9%   Top

Re: filtering /48 is going to be necessary

[Brandon Butterworth]

> From: Owen DeLong 
> > We had this discussion on the list exactly a year ago.  At that time,
> > the average IPv6 origin ASN was announcing 1.43 routes.  That figure
> > today is 1.57 routes per origin ASN.
> 
> That represents a 10% growth in prefix/asn for IPv6.
> 
> Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While
> I would agree that this is a trend that merits watching, I think
> we're probably OK for quite some time.

By the time it's a problem it'll not be fixable.

I've been a supporter of classful allocation of v6 such as Bill mentioned
(http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html)
there's enough space for it but people don't want to do classful again.

If there isn't standard filtering of defined prefix/lengths by major
carriers then we're just waiting for the problem to arrive. I don't
think we'd get enough people to agree on this to avoid it.

brandon

BGP MD5 at IXP

[Jay Hanke]

How critical is BGP MD5 at Internet Exchange Points? Would lack of
support for MD5 authentication on route servers prevent some peers
from multilaterally connecting? Do most exchange operators support it?

Thanks!

Jay

Re: BGP MD5 at IXP

[Patrick W. Gilmore]

On Mar 9, 2012, at 17:24 , Jay Hanke wrote:

> How critical is BGP MD5 at Internet Exchange Points? Would lack of
> support for MD5 authentication on route servers prevent some peers
> from multilaterally connecting? Do most exchange operators support it?



Search for MD5.

Most IXP route servers support it, few require it.  So even if you do it on 
your side, doesn't mean someone else did it on their side.

I've never seen anyone refuse to connect to an IXP route server that did not, 
but that doesn't mean it hasn't happened.

-- 
TTFN,
patrick

Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 9, 2012, at 12:50 PM, Bernhard Schmidt wrote:

> On 09.03.2012 20:31, Owen DeLong wrote:
> 
> Hi,
> 
>> Let us not forget that there is also the issue of PA /48s being
>> advertised (quasi-legitimately) for some end-user organizations that
>> are multi-homed but choose not to get PI space. It is not uncommon to
>> obtain a PA /48 from provider A and also advertise it from Provider
>> B.
> 
> While I agree it's not uncommon, I'm not a big fan of this setup. Also, 
> provider A should still have his aggregate announced, which would allow 
> strictly filtering ISPs to reach the destination anyway.
> 

I'm not a big fan, either, but, I think that the concept of "be conservative in 
what you announce and liberal in what you accept" has to apply in this case. 
Since it is a common (quasi-)legitimate practice, arbitrarily filtering it is 
ill-advised IMHO.

The statement about the covering aggregate assumes that there are no failures 
in the union of {site, loop, provider A}.

In the event that there is such a failure, the aggregate may not help and may 
even be harmful.

Since one of the key purposes of this kind of multihoming is to provide 
coverage in the event of such a failure, filtration of the more-specific seems 
to defeat the purpose.

> Announcing /48s from a PA block without the covering aggregate calls for 
> trouble.

No question. However, the covering aggregate alone is also insufficient.

Owen

Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 9, 2012, at 2:07 PM, Brandon Butterworth wrote:

>> From: Owen DeLong 
>>> We had this discussion on the list exactly a year ago.  At that time,
>>> the average IPv6 origin ASN was announcing 1.43 routes.  That figure
>>> today is 1.57 routes per origin ASN.
>> 
>> That represents a 10% growth in prefix/asn for IPv6.
>> 
>> Compare to 9.3->9.96/ASN (7%) in IPv4 over that same time, While
>> I would agree that this is a trend that merits watching, I think
>> we're probably OK for quite some time.
> 
> By the time it's a problem it'll not be fixable.
> 
> I've been a supporter of classful allocation of v6 such as Bill mentioned
> (http://lists.arin.net/pipermail/arin-ppml/2009-November/015521.html)
> there's enough space for it but people don't want to do classful again.
> 
> If there isn't standard filtering of defined prefix/lengths by major
> carriers then we're just waiting for the problem to arrive. I don't
> think we'd get enough people to agree on this to avoid it.
> 
> brandon

My opposition to this ill-conceived idea has nothing to do with favor of nor 
opposition to classful addressing.

My opposition comes from the fact that this could very easily become an 
additional tool used by larger players in the peering wars to disadvantage 
smaller players. Handing one side an RIR-sponsored tactical nuclear weapon is, 
IMHO, on the face of it a bad idea. The proposal for classful allocation that 
Bill floated in the thread above would constitute doing exactly that. If you 
will review the thread, you will find that is my stated reason for opposition 
at the time as well.

Owen

Re: filtering /48 is going to be necessary

[Jimmy Hess]

On Fri, Mar 9, 2012 at 1:31 PM, Owen DeLong  wrote:
> Let us not forget that there is also the issue of PA /48s being advertised 
> (quasi-legitimately) for some end-user organizations that are multi-homed but 
> choose not to get PI space. It is not uncommon to obtain a PA /48 from 
> provider A and also advertise it from Provider B.

What should happen is this  "quasi-legitimate"  method  of
multi-homing should just be declared illegitimate for IPv6, to
facilitate stricter filtering. Instead, what should happen is the
multi-homing should be required to fit into one of 3 scenarios,  so
any announcement with an IPv6 prefix length other than the
RIR-allocated/assigned PA or PI block size can be  treated as TE and
summarily discarded or prioritizes when table resources are scarce.

Scenario (1) The end user org  obtains PI address space from a RIR,
and originates their assigned prefix.  The end user org originates
their RIR assigned exact prefix and announces to their upstreams,  who
filter and accept from the end user only routes containing a NLRI of
their exact prefix,  with the prefix length used by the RIR for the PI
blocks from which their assignment(s) had been made.

(2) Same as (1) but The RIR provides some expedited process for the
ISP to obtain and transfer PI space and  AS numbers for the purpose of
their customers'  multihoming - in one step,  so the end user does not
have to figure out the RIR application process  --  E.g.  some RIR
process provides the ISP an option to create PI blocks on demand in
addition to their PA block;  the ISP will not know in advance what AS
number or PI block will be allocated,the ISP must follow the RIR
rules for the assignment of PI blocks,  and educate their user as
needed,  obtain a signed RSA with the End user, obtain written proof
the user has two ISPs, has provided a network design that includes
multihoming, and a written sound justification for the multi-homing
or the meeting of a criteria requiring multihoming,  provide the End
User's billing contact info to the RIR,  the ISP having pre-payed
registration fees to the RIR  --- should the end user stop using the
ISP that created the block,  responsibility for the PI block and AS
numbers reverts to the end user org.


(3)   The  end user org  who is multi-homed picks a 3rd party
organization to assign to the end user from their PA block.   The 3rd
party org's overall  PA block is multihomed with diverse connectivity,
 and the end user inherits the multihoming  of the 3rd party's PA
block.

  The 3rd party AS is the sole AS that originates  the prefix in the
form of the entire PA block into the DFZ   and then routes the
individually assigned end-user block to the End user  through private
arrangement or peering  with the  End user orgs'  upstreams,

(IOW: the multi-homed users block does not appear as a globally
visible more-specific/deaggregate)


(4) Any of the other methods of achieving multi-homing,  such as
originating an NLRI with a longer prefix than the RIR delegation,
should be rejected by filters.

> Owen
--
-JH

Re: filtering /48 is going to be necessary

[Sander Steffann]

Hi,

> What should happen is this  "quasi-legitimate"  method  of
> multi-homing should just be declared illegitimate for IPv6, to
> facilitate stricter filtering. Instead, what should happen is the
> multi-homing should be required to fit into one of 3 scenarios,  so
> any announcement with an IPv6 prefix length other than the
> RIR-allocated/assigned PA or PI block size can be  treated as TE and
> summarily discarded or prioritizes when table resources are scarce.

Splitting the allocation can be done for many reasons. There are known cases 
where one LIR operates multiple separate networks, each with a separate routing 
policy. They cannot get multiple allocations from the RIR and they cannot 
announce the whole allocation as a whole because of the separate routing 
policies (who are sometimes required legally, for example when an NREN has both 
a commercial and an educational network). Deaggregating to /48's is not a good 
idea, but giving an LIR a few bits (something like 3 or 4) to deaggregate makes 
sense.

- Sander

Re: filtering /48 is going to be necessary

[Jimmy Hess]

On Fri, Mar 9, 2012 at 5:32 PM, Sander Steffann  wrote:
> Splitting the allocation can be done for many reasons. There are known cases 
> where one LIR >operates multiple separate networks, each with a separate 
> routing policy. They cannot get multiple >allocations from the RIR and they 
> cannot announce the whole allocation as a whole because of the >separate 
> routing policies (who are sometimes required legally, for example when an 
> NREN has both a >commercial and an educational network). Deaggregating to 
> /48's is not a good idea, but giving an LIR

It does make sense to give the LIR a few bits.
Note though I say what "should" happen.

What will happen in actual fact,  is probably going to be identical to IPv4.
End users will go to other ISPs and demand they carry their individual /64s;
resulting market pressure is more powerful than efficient design.

--
-JH

Re: filtering /48 is going to be necessary

[George Herbert]

If the LIRs cannot get separate allocations from the RIR (and separate
ASNs) for this usage, something is wrong.

We want to make things as simple and efficient as possible, but no
simpler or more efficient, because the curves go back up again at that
point, and we all suffer.


-george

On Fri, Mar 9, 2012 at 3:32 PM, Sander Steffann  wrote:
> Hi,
>
>> What should happen is this  "quasi-legitimate"  method  of
>> multi-homing should just be declared illegitimate for IPv6, to
>> facilitate stricter filtering. Instead, what should happen is the
>> multi-homing should be required to fit into one of 3 scenarios,  so
>> any announcement with an IPv6 prefix length other than the
>> RIR-allocated/assigned PA or PI block size can be  treated as TE and
>> summarily discarded or prioritizes when table resources are scarce.
>
> Splitting the allocation can be done for many reasons. There are known cases 
> where one LIR operates multiple separate networks, each with a separate 
> routing policy. They cannot get multiple allocations from the RIR and they 
> cannot announce the whole allocation as a whole because of the separate 
> routing policies (who are sometimes required legally, for example when an 
> NREN has both a commercial and an educational network). Deaggregating to 
> /48's is not a good idea, but giving an LIR a few bits (something like 3 or 
> 4) to deaggregate makes sense.
>
> - Sander
>
>



-- 
-george william herbert
george.herb...@gmail.com

RE: filtering /48 is going to be necessary

[Leo Vegoda]

Hi,

Sander wrote:

> Splitting the allocation can be done for many reasons. There are known cases 
> where one LIR operates multiple separate networks, each with a separate 
> routing policy. They cannot get multiple allocations from the RIR and they 
> cannot announce the whole allocation as a whole because of the separate 
> routing policies (who are sometimes required legally, for example when an 
> NREN has both a commercial and an educational network).

If they have two different routing policies and need two different allocations, 
why not just have two different LIRs? It makes things a lot easier than 
spending untold weeks or time trying to work out which corner cases should be 
supported by policy and which should not. No?

Leo

Re: filtering /48 is going to be necessary

[Brandon Butterworth]

> From: Owen DeLong 
> Handing one side an RIR-sponsored
> tactical nuclear weapon is, IMHO, on the face of it a bad idea. The
> proposal for classful allocation that Bill floated in the thread above
> would constitute doing exactly that

Certainly a risk but then we handed every nutter with BGP a
dirty nuclear bomb instead.

brandon

AT&T home DSL IPv6 configuration?

[Chris Adams]

I have some friends and family in various places that have AT&T DSL.  At
least one has been upgraded to IPv6 support (I connected my notebook to
his wireless router and was suprised to see I logged into my server over
IPv6).  As they tend to ask me for help now and then, I was trying to
see how AT&T configured IPv6 for their residential DSL customers, but I
can't find anything on their site.  They only talk about the routers
they sell, and if you don't have one of those, they link to their store
to buy one.

Can anybody tell me how they are configuring their IPv6 setup?
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

RE: filtering /48 is going to be necessary

[George Bonser]

> Owen said:
> 
> I'm not a big fan, either, but, I think that the concept of "be
> conservative in what you announce and liberal in what you accept" has
> to apply in this case. Since it is a common (quasi-)legitimate
> practice, arbitrarily filtering it is ill-advised IMHO.

While I agree in principle, 16 bits of disaggregation has the potential for a 
lot of mayhem and 32 bits (accepting /64 from PA) would be catastrophic.  This 
would seem to be a case where upstream providers can assist the end user in 
obtaining their own PI space if they wish to multihome.  It would be in the 
provider's interest as it would reduce the number of potential complaints from 
customers concerning multihoming problems.

I filter /32 from PA space and am currently filtering one route but since the 
aggregate it is from has the same next hop and since I don't see the route from 
anyone else, I'm not worried about it.

RE: filtering /48 is going to be necessary

[George Bonser]

> Deaggregating to /48's is not a good idea, but giving an LIR a few bits
> (something like 3 or 4) to deaggregate makes sense.
> 
> - Sander
> 

+1

I wouldn't have a problem with a few bits of disaggregation. That seems 
reasonable for a network that might be subject to partitioning or doesn't have 
a fully meshed internal net.

Re: filtering /48 is going to be necessary

[Owen DeLong]

This varies from RIR to RIR.

In the ARIN region, you can get assignments or allocations for Multiple 
Discreet Networks, but, ARIN will often register them as an aggregate in the 
registration database, so...

In the RIPE region (which is where I believe Sander is), only aggregates are 
available to the best of my knowledge.

Owen

On Mar 9, 2012, at 3:40 PM, George Herbert wrote:

> If the LIRs cannot get separate allocations from the RIR (and separate
> ASNs) for this usage, something is wrong.
> 
> We want to make things as simple and efficient as possible, but no
> simpler or more efficient, because the curves go back up again at that
> point, and we all suffer.
> 
> 
> -george
> 
> On Fri, Mar 9, 2012 at 3:32 PM, Sander Steffann  wrote:
>> Hi,
>> 
>>> What should happen is this  "quasi-legitimate"  method  of
>>> multi-homing should just be declared illegitimate for IPv6, to
>>> facilitate stricter filtering. Instead, what should happen is the
>>> multi-homing should be required to fit into one of 3 scenarios,  so
>>> any announcement with an IPv6 prefix length other than the
>>> RIR-allocated/assigned PA or PI block size can be  treated as TE and
>>> summarily discarded or prioritizes when table resources are scarce.
>> 
>> Splitting the allocation can be done for many reasons. There are known cases 
>> where one LIR operates multiple separate networks, each with a separate 
>> routing policy. They cannot get multiple allocations from the RIR and they 
>> cannot announce the whole allocation as a whole because of the separate 
>> routing policies (who are sometimes required legally, for example when an 
>> NREN has both a commercial and an educational network). Deaggregating to 
>> /48's is not a good idea, but giving an LIR a few bits (something like 3 or 
>> 4) to deaggregate makes sense.
>> 
>> - Sander
>> 
>> 
> 
> 
> 
> -- 
> -george william herbert
> george.herb...@gmail.com

Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 9, 2012, at 4:33 PM, Brandon Butterworth wrote:

>> From: Owen DeLong 
>> Handing one side an RIR-sponsored
>> tactical nuclear weapon is, IMHO, on the face of it a bad idea. The
>> proposal for classful allocation that Bill floated in the thread above
>> would constitute doing exactly that
> 
> Certainly a risk but then we handed every nutter with BGP a
> dirty nuclear bomb instead.
> 
> brandon

More like a small grenade which can be easily defused by their upstream at will.

Owen

Re: filtering /48 is going to be necessary

[Owen DeLong]

> 
> (4) Any of the other methods of achieving multi-homing,  such as
> originating an NLRI with a longer prefix than the RIR delegation,
> should be rejected by filters.
> 
>> Owen
> --
> -JH

It is very rare that I will quote Randy Bush. Even more so when his
original quote was utterly misplaced in the original context.

However, in this case I will make an exception...

"We don't need policy weenies telling us how to run our networks."
--Randy Bush (from APNIC Policy SIG discussion of Prop-098)

Owen

Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 9, 2012, at 3:45 PM, Leo Vegoda wrote:

> Hi,
> 
> Sander wrote:
> 
>> Splitting the allocation can be done for many reasons. There are known cases 
>> where one LIR operates multiple separate networks, each with a separate 
>> routing policy. They cannot get multiple allocations from the RIR and they 
>> cannot announce the whole allocation as a whole because of the separate 
>> routing policies (who are sometimes required legally, for example when an 
>> NREN has both a commercial and an educational network).
> 
> If they have two different routing policies and need two different 
> allocations, why not just have two different LIRs? It makes things a lot 
> easier than spending untold weeks or time trying to work out which corner 
> cases should be supported by policy and which should not. No?
> 
> Leo


This may depend on where you are. Being two LIRs in the ARIN region requires 
setting up two complete legal entities which is a lot of overhead to carry for 
just that purpose.

Owen

Re: filtering /48 is going to be necessary

[Joel jaeggli]

On 3/9/12 20:42 , Owen DeLong wrote:
> 
> On Mar 9, 2012, at 3:45 PM, Leo Vegoda wrote:
> 
>> Hi,
>> 
>> Sander wrote:
>> 
>>> Splitting the allocation can be done for many reasons. There are 
>>> known cases where one LIR operates multiple separate networks, 
>>> each with a separate routing policy. They cannot get multiple 
>>> allocations from the RIR and they cannot announce the whole 
>>> allocation as a whole because of the separate routing policies 
>>> (who are sometimes required legally, for example when an NREN
>>> has both a commercial and an educational network).
>> 
>> If they have two different routing policies and need two different 
>> allocations, why not just have two different LIRs? It makes things 
>> a lot easier than spending untold weeks or time trying to work out 
>> which corner cases should be supported by policy and which should 
>> not. No?
>> 
>> Leo
> 
> 
> This may depend on where you are. Being two LIRs in the ARIN region 
> requires setting up two complete legal entities which is a lot of 
> overhead to carry for just that purpose.
> 
> Owen
> 
I'll put this as bluntly and succinctly as I can because I find the LIR
distriction arbitrary...

I have an ipv6 direct assignment from ARIN.

It is sized to meet the needs of my enterprise consistent with needs for
future growth number of pops, prevailing ARIN policy etc.

Because my network is discontiguous I must announce more specific routes
than the assignment in order to reflect the topology I have both in IPV4
and in IPV6.

I fully expect (and have no evidence to the contrary) that my transit
providers will accept the deaggreated prefixes and that their upstreams
and peers will by-in-large do likewise.

I have no interest in the general sense of deaggregating beyond the
level required by the topological considerations.

Imposing arbitary political considerations on organizations that are
simply trying to operate networks in order preserve maximal aggregation
at a given level seems absurd on the face of it.

I am reasonably certain that every wholesale transit provider on this
list that offers ipv6 transit would be willing to accept by money and
route my prefixes in their current form.

Re: filtering /48 is going to be necessary

[Randy Bush]

> Imposing arbitary political considerations on organizations that are
> simply trying to operate networks in order preserve maximal
> aggregation at a given level seems absurd on the face of it.

arin policy weenies live for this!

randy

RE: filtering /48 is going to be necessary

[George Bonser]

> I'll put this as bluntly and succinctly as I can because I find the LIR
> distriction arbitrary...
> 
> I have an ipv6 direct assignment from ARIN.

I am assuming you are an enterprise in PI space and not an ISP in PA space?

 
> It is sized to meet the needs of my enterprise consistent with needs
> for future growth number of pops, prevailing ARIN policy etc.
> 
> Because my network is discontiguous I must announce more specific
> routes than the assignment in order to reflect the topology I have both
> in IPV4 and in IPV6.

> I fully expect (and have no evidence to the contrary) that my transit
> providers will accept the deaggreated prefixes and that their upstreams
> and peers will by-in-large do likewise.

If you are in PI space, I believe most people take down to a /48 as a /48 is 
generally accepted to be a single "site".  So let's say you were given a /40 
and have several disconnected sites.  Most people are going to accept a /48 
from you in PI space. I would say pretty close to "everyone" is going to accept 
a /48 from PI space.

An ISP that has been given a /32 or larger allocation from PA space and might 
have 10,000 customers each assigned their own /48 could instantly more than 
double the size of the IPv6 routing table if they disaggregated that /32.  

The problem here is that each /32 is 65536 /48 networks.  An even larger net, 
say a /30 that disaggregates due to a router configuration goof means a 
potential of a huge number of networks suddenly flooding the Internet.

Re: filtering /48 is going to be necessary

[Jimmy Hess]

On Fri, Mar 9, 2012 at 11:33 PM, Joel jaeggli  wrote:
> On 3/9/12 20:42 , Owen DeLong wrote:

> Because my network is discontiguous I must announce more specific routes
> than the assignment in order to reflect the topology I have both in IPV4
> and in IPV6.
>
> I fully expect (and have no evidence to the contrary) that my transit
> providers will accept the deaggreated prefixes and that their upstreams
> and peers will by-in-large do likewise.

I have no doubt any transit provider would be happy to provide the
transit for your discontiguous network, and accept your deaggregates
within their network.The unreasonable expectation is that their
upstreams or peers would carry all the deaggregates in the long run.

Connectivity for your discontiguous networks are your problem to
solve,  and as long as router memory is at a premium,  limiting what
deaggregates are accepted will be important.

The peers want best connectivity to you at least cost for them.

> I have no interest in the general sense of deaggregating beyond the
> level required by the topological considerations.

You don't have such an interest,  but  sloppy practices prevail on average.
As evidenced in IPv4 by  large blocks with all the /24s showing up.

> Imposing arbitary political considerations on organizations that are

Not political considerations, technical restrictions,  which are
design constraints.
There are already plenty such design constraints that are imposed by RFC;
interconnecting networks doesn't have a reliable result without some technical
ground rules  that provide for interoperability,  stability, and predictability.


> simply trying to operate networks in order preserve maximal aggregation
> at a given level seems absurd on the face of it.

So for any network you provide transit to, in IPv4 you would be happy
to allow them to
announce their /12  as   13,1072   /29s,  because they have 131072 subnets,
and they could reasonably expect  that all your peers  would be happy to
propagate the /29s,for the purpose of making sure the end user's
design is not constrained
(although at the peer's  expense for increased equipment capacity) ?

There's an unwritten rule somewhere,  that you don't expect longer than a /24
to propagate far  with high degree of certainty.

With IPv6  instead of picking some arbitrary number  liek /48 or /64,
it should be based on the RIR allocation unit size and type of
allocation,  for best results.

That's more rational than what we have with IPv4

-- 
-JH

Re: Questions about anycasting setup

[Anurag Bhatia]

Thanks for guidance everyone!


Appreciate it.

And yes, I can see another thread running on discussion about /48 - I am
listening silently about it.

Multiple AS doing anycasting was little concern for me, but now seems good
since I can see everyone's suggestion to use single own ASN for anycasting.

On Fri, Mar 9, 2012 at 3:25 PM, Pete Carah  wrote:

> On 03/09/2012 01:34 AM, Elmar K. Bins wrote:
> > Re Bill,
> >
> > wo...@pch.net (Bill Woodcock) wrote:
> >
> >>> Well, let's say, using Quagga/BIRD might not really be best practice
> for
> >>> everybody... (e.g., *we* are using Cisco equipment for this)
> >> How does your Cisco know whether an adjacent nameserver is heavily
> loaded, and adjust its BGP announcements accordingly?
> > It doesn't have to.
> >
> > I don't know how you guys do it, but we take great care to
> > keep min. 70% overhead capacity during standard operation.
> >
> My point had to do with resilience in the face of hardware/OS/software
> failures in the box providing the
> service.  Bill's has more to do with resilience in the face of other
> network events (e.g. the upstream for one
> of the boxes has a DDOS; you cannot reasonably provide enough excess
> capacity to handle that...)  Neither of these is addressed by using a
> separate router to announce the server's anycast route.  (unless somehow
> the Cisco is providing the anycasted service, which would address my
> concern but still not Bill's.)
>
> Also, Bill is probably talking root (or bigger public) servers whose
> load comes from "off-site"; the average load characteristics for those
> are well known but there can be extremes that would be hard to plan for
> (hint - operating at 30% isn't really good enough, probably not 10%
> either.  Bill (and the other Bill) have pretty good stats for this that
> I've only glanced at...)  And it is easy to see where one of the
> extremes might hit only one or two of the anycast instances.  He implies
> having the instances talking to each other in background to adjust bgp
> announcements to maybe help level things.  Fortunately at least for the
> root servers, the redundancy is at two levels and anycast is only one of
> them.
>
> -- Pete
>
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

Concern about gTLD servers in India

[Anurag Bhatia]

Hello everyone,


Greetings from India. I hope lot of you have enjoyed APRICOT event at New
Delhi.

I wanted to bring an important issue. It's about DNS root servers in India.

So

anurag@laptop:~$ dig . ns +short
i.root-servers.net.
e.root-servers.net.
j.root-servers.net.
l.root-servers.net.
k.root-servers.net.
d.root-servers.net.
h.root-servers.net.
f.root-servers.net.
m.root-servers.net.
c.root-servers.net.
a.root-servers.net.
g.root-servers.net.
b.root-servers.net.


I can see India has 3 root servers hosting root zone - i, j & k in India
which is good. So we can resolve the root zone i.e dot within India.

Next, looking gTLD servers used by popular TLDs like com/net/org:

anurag@laptop:~$ dig com. ns +short
g.gtld-servers.net.
f.gtld-servers.net.
a.gtld-servers.net.
h.gtld-servers.net.
e.gtld-servers.net.
d.gtld-servers.net.
j.gtld-servers.net.
i.gtld-servers.net.
c.gtld-servers.net.
m.gtld-servers.net.
l.gtld-servers.net.
k.gtld-servers.net.
b.gtld-servers.net.


None of these gTLD root servers are in India. I have tested routes to each
of them from BSNL (AS9829), Tata Comm (AS4755 & AS6453), Airtel (AS9498) -
all land up outside India - most of them in Europe and US, and couple of
them in Singapore, and one in Australia. Why so? Please correct me if I am
wrong on this analysis but this seems not efficient setup to me. Any damage
on outside connectivity (which is common with Earthquakes or ships hitting
submarine fiber, and eventually opposite route getting chocked with
traffic) - can cause huge issues on sites which are hosted within India.



And so this is how google.com is resolved in India:

anurag@laptop:~$ dig google.com +trace

; <<>> DiG 9.7.1-P2 <<>> google.com +trace
;; global options: +cmd
. 11352 IN NS i.root-servers.net.
. 11352 IN NS e.root-servers.net.
. 11352 IN NS j.root-servers.net.
. 11352 IN NS l.root-servers.net.
. 11352 IN NS k.root-servers.net.
. 11352 IN NS d.root-servers.net.
. 11352 IN NS h.root-servers.net.
. 11352 IN NS f.root-servers.net.
. 11352 IN NS m.root-servers.net.
. 11352 IN NS c.root-servers.net.
. 11352 IN NS a.root-servers.net.
. 11352 IN NS g.root-servers.net.
. 11352 IN NS b.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 57 ms

com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 491 bytes from 128.63.2.53#53(h.root-servers.net) in 264
ms  - Hitting
outside root server, but anyways alternate i,j,k are up in India so good
overall.

google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; Received 164 bytes from 192.5.6.30#53(a.gtld-servers.net) in 315 ms
- Hitting
outside server and it will always hit outside since no server here. Problem.

google.com. 300 IN A 173.194.36.3
google.com. 300 IN A 173.194.36.4
google.com. 300 IN A 173.194.36.0
google.com. 300 IN A 173.194.36.2
google.com. 300 IN A 173.194.36.8
google.com. 300 IN A 173.194.36.1
google.com. 300 IN A 173.194.36.5
google.com. 300 IN A 173.194.36.7
google.com. 300 IN A 173.194.36.6
google.com. 300 IN A 173.194.36.14
google.com. 300 IN A 173.194.36.9
;; Received 204 bytes from 216.239.32.10#53(ns1.google.com) in 305 ms





Also, looking at reverse DNS root servers:

anurag@laptop:~$ dig in-addr.arpa. ns +short
a.in-addr-servers.arpa.
b.in-addr-servers.arpa.
c.in-addr-servers.arpa.
d.in-addr-servers.arpa.
e.in-addr-servers.arpa.
f.in-addr-servers.arpa.



Again, none of these hosted in India. So for each email sent within any
domains across India - during smtp check, rDNS is resolved from outside
world? (SMTP auth. being one of mail roles of rDNS besides few others). I
have collected data about paths from popular Indian backbones to each of
these servers. If anyone interested, please let me know.


*Sidenote: I know NANOG is primarily for North America but I
really appreciate good replies and was wondering if someone can tell me if
my understanding is wrong.*

Very much interested in hearing comments from community on this.


Thanks.

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

Re: filtering /48 is going to be necessary

[Joel jaeggli]

On 3/9/12 22:02 , George Bonser wrote:

> An ISP that has been given a /32 or larger allocation from PA space
> and might have 10,000 customers each assigned their own /48 could
> instantly more than double the size of the IPv6 routing table if they
> disaggregated that /32.
> 
> The problem here is that each /32 is 65536 /48 networks.  An even
> larger net, say a /30 that disaggregates due to a router
> configuration goof means a potential of a huge number of networks
> suddenly flooding the Internet.

I'm well into my second decade of having a v6 prefix in the dfz and am
passingly familiar with powers of two...

Re: filtering /48 is going to be necessary

[Owen DeLong]

On Mar 9, 2012, at 7:08 PM, George Bonser wrote:

>> Owen said:
>> 
>> I'm not a big fan, either, but, I think that the concept of "be
>> conservative in what you announce and liberal in what you accept" has
>> to apply in this case. Since it is a common (quasi-)legitimate
>> practice, arbitrarily filtering it is ill-advised IMHO.
> 
> While I agree in principle, 16 bits of disaggregation has the potential for a 
> lot of mayhem and 32 bits (accepting /64 from PA) would be catastrophic.  
> This would seem to be a case where upstream providers can assist the end user 
> in obtaining their own PI space if they wish to multihome.  It would be in 
> the provider's interest as it would reduce the number of potential complaints 
> from customers concerning multihoming problems.
> 
> I filter /32 from PA space and am currently filtering one route but since the 
> aggregate it is from has the same next hop and since I don't see the route 
> from anyone else, I'm not worried about it.

I haven't heard anyone advocate accepting less than a /48. I think /48 is a 
reasonable "You must be this tall to ride" barrier.

Beyond that, YMMV.

Owen

RE: filtering /48 is going to be necessary

[George Bonser]

> 
> I'm well into my second decade of having a v6 prefix in the dfz and am
> passingly familiar with powers of two...
> 

Point is that expecting people globally to take a /48 from PA space probably 
isn't a realistic expectation.

Re: Questions about anycasting setup

[Steve Gibbard]

On Mar 9, 2012, at 1:01 AM, Pete Carah wrote:

>> Well, let's say, using Quagga/BIRD might not really be best practice for
>> everybody... (e.g., *we* are using Cisco equipment for this)
> Actually there is a *very* good reason why many (most?) anycast
> instances use quagga/BIRD/gated/etc
> to speak bgp (or even ospf for internal anycast) which using a Cisco (or
> any separate router) usually won't accomplish.

I've done this two ways.

I've used Quagga to announce routes directly from the anycast servers.  This 
guarantees you that the route will go away if the server completely goes away, 
and that traffic will be directed elsewhere.  It also allows you to run scripts 
on the servers that can withdraw the routes in other circumstances, such as if 
a script running on the server detects that the server is non-responsive (or 
overloaded).

I've used load balancers in front of the name servers.  Like Quagga running 
directly on the server, a load balancer can withdraw routes when all servers 
behind it stop responding.  It has some advantages, in that it can withdraw 
routes to non-responsive servers even in cases where the server may be too 
confused to detect its own problems and send the appropriate messages to 
Quagga.   It can spread load among a larger collection of servers than a router 
would be able to on its own, sit in front of the servers and do rate limiting, 
and things like that.  It could help with the overload issue Bill mentions by 
selectively sending some queries to other sites without the all or nothing 
effect you get from a BGP route withdrawal.  On the other hand, load balancers 
aren't cheap, and and once installed in the middle of a network they become one 
more device to fail.

I have no idea what Cisco equipment Elmar is using, but I wouldn't jump to the 
conclusion that it can't withdraw routes when needed.

-Steve

RE: filtering /48 is going to be necessary

[George Bonser]

> I haven't heard anyone advocate accepting less than a /48. I think /48
> is a reasonable "You must be this tall to ride" barrier.
> 
> Beyond that, YMMV.
> 
> Owen

Apparently AS6939 has at various times :)  I remember getting some /64 
announcements from HE.  I haven't seen one lately, though.  I'm only filtering 
one /64 route these days announced by AS4651 

Re: Concern about gTLD servers in India

[Graham Beneke]

On 10/03/2012 08:19, Anurag Bhatia wrote:

Next, looking gTLD servers used by popular TLDs like com/net/org:





None of these gTLD root servers are in India. I have tested routes to each
of them from BSNL (AS9829), Tata Comm (AS4755&  AS6453), Airtel (AS9498) -
all land up outside India - most of them in Europe and US, and couple of
them in Singapore, and one in Australia. Why so? Please correct me if I am
wrong on this analysis but this seems not efficient setup to me. Any damage
on outside connectivity (which is common with Earthquakes or ships hitting
submarine fiber, and eventually opposite route getting chocked with
traffic) - can cause huge issues on sites which are hosted within India.


This problem is unfortunately not unique to India. There appear to be no 
anycast instances of the gTLD servers in Africa either.


I am 180-500ms away from the gTLD servers right now.


Also, looking at reverse DNS root servers:

anurag@laptop:~$ dig in-addr.arpa. ns +short
a.in-addr-servers.arpa.
b.in-addr-servers.arpa.
c.in-addr-servers.arpa.
d.in-addr-servers.arpa.
e.in-addr-servers.arpa.
f.in-addr-servers.arpa.


These servers are operated by the RIRs. Its probably worth contacting 
APNIC to find out how to get an anycast instance installed at you local 
internet exchange point.


--
Graham Beneke

RE: filtering /48 is going to be necessary

[George Bonser]

>  I'm only
>  filtering one /64 route these days announced by AS4651
> 
> 

Actually AS4651 is announcing it to me but it is originating from AS23883 via 
AS4750 so there are some folks out there taking /64 routes. That one hit my 
filters, though.

Re: Concern about gTLD servers in India

[Randy Bush]

> This problem is unfortunately not unique to India. There appear to be no 
> anycast instances of the gTLD servers in Africa either.

really!?

Re: Concern about gTLD servers in India

[Anurag Bhatia]

Hello Randy


No idea about Africa but certainly none of gTLD servers in India.

On Sat, Mar 10, 2012 at 12:42 PM, Randy Bush  wrote:

> > This problem is unfortunately not unique to India. There appear to be no
> > anycast instances of the gTLD servers in Africa either.
>
> really!?
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

Re: Concern about gTLD servers in India

[Frank Habicht]

On 3/10/2012 10:12 AM, Randy Bush wrote:
>> This problem is unfortunately not unique to India. There appear to be no 
>> anycast instances of the gTLD servers in Africa either.
> 
> really!?

There was one in KE but can't find or reach it:
[a-m].gtld-servers.net.  seem all to be in 192.0.0.0/8

route-views.kixp.routeviews.org> sh ip bgp 192.0.0.0/8 lo
route-views.kixp.routeviews.org>

Likely there is still (?) in EG ...?

Frank

Re: Concern about gTLD servers in India

[Graham Beneke]

On 10/03/2012 09:12, Randy Bush wrote:

This problem is unfortunately not unique to India. There appear to be no
anycast instances of the gTLD servers in Africa either.


really!?


Yes. I was also a little surprised.

I'm sure that I read somewhere that at least one of the gTLD anycast 
prefixes was available at JINX (although I've never actually confirmed 
that).


I've gone through every permutation of

mtr [-4|-6] [a-m].gtld-servers.net.

again just to be sure. I'm reaching nothing on this continent.

--
Graham Beneke

Re: Concern about gTLD servers in India

[Anurag Bhatia]

I am sure few of people here have experience of running root servers.

Can someone share if there's huge difference in . root servers Vs gTLD
servers? I understand that root only hold all TLD's  - cc and gTLD
delegation that would be few hundred TLDs delegation while gTLDs hold lot
of domain names but if one country has root, what prevents having gTLD
also? Certainly bit more hardware, storage and processing power but such
facilities are available mostly say in India & South Africa which have
significant number of big telcos.




On Sat, Mar 10, 2012 at 12:52 PM, Graham Beneke  wrote:

> On 10/03/2012 09:12, Randy Bush wrote:
>
>> This problem is unfortunately not unique to India. There appear to be no
>>> anycast instances of the gTLD servers in Africa either.
>>>
>>
>> really!?
>>
>
> Yes. I was also a little surprised.
>
> I'm sure that I read somewhere that at least one of the gTLD anycast
> prefixes was available at JINX (although I've never actually confirmed
> that).
>
> I've gone through every permutation of
>
> mtr [-4|-6] [a-m].gtld-servers.net.
>
> again just to be sure. I'm reaching nothing on this continent.
>
> --
> Graham Beneke
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com

Re: Concern about gTLD servers in India

[Randy Bush]

> No idea about Africa

then on what basis did you make the assertion?

> but certainly none of gTLD servers in India.

i am slightly suspicious of this.  often, root servers are accompanied
by gtld servers, and there are more than zero root servers in india.

there is a fashion among root and gtld servers to attempt to limit the
scope of their ancast routing announcements.  this makes them hard to
find from a (topologic) distance.

randy

Re: Concern about gTLD servers in India

[Anurag Bhatia]

Please don't create confusions.

I didn't made any assertion. I mentioned issue with India, but Graham came
with point that issue is similar in Africa. Good point if he knows that.
Certainly relevent to issue I mentioned for India.

Again - I have not verified this. I don't know much about ISPs in Africa to
find their looking glasses and test routing.

On Sat, Mar 10, 2012 at 1:00 PM, Randy Bush  wrote:

> > No idea about Africa
>
> then on what basis did you make the assertion?
>
> > but certainly none of gTLD servers in India.
>
> i am slightly suspicious of this.  often, root servers are accompanied
> by gtld servers, and there are more than zero root servers in india.
>
> there is a fashion among root and gtld servers to attempt to limit the
> scope of their ancast routing announcements.  this makes them hard to
> find from a (topologic) distance.
>
> randy
>


Ok, here's some data I collected couple of months back. I did consistant
lookup for days to be sure that it's not temporary routing glitch giving
such results.


Traceroute to gTLDs from BSNL AS9829 -
http://cdn.anuragbhatia.com/uploads/2012/03/gtld-traceroute-bsnl-as9829.txt

Traceroute to gTLDs from Bharti Airtel AS9498 -
http://cdn.anuragbhatia.com/uploads/2012/03/gtld-traceroute-airtel-as9498.txt

Traceroutes to rDNS in-addr.arpa servers from BSNL -
http://cdn.anuragbhatia.com/uploads/2012/03/rdns-bsnl-as9829.txt

Traceroutes to rDNS in-addr.arpa servers from Airtel -
http://cdn.anuragbhatia.com/uploads/2012/03/rdns-airtel-as9498.txt


Thanks for your time & comments.


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia 
Linkedin: http://linkedin.anuragbhatia.com