Mailing List Archive: nsp: ipv6

IPV6 route registries

Index | Next | Previous | View Threaded

mhuff at ox

Sep 13, 2011, 9:03 AM

Post #1 of 19 (1634 views)
Permalink

IPV6 route registries

Given that we are a private org, and not an ISP, is there any place we should be registering our ASN/routes other than RADB for ipv6?

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff | Fax: 914-460-4139

nick at foobar

Sep 13, 2011, 9:07 AM

Post #2 of 19 (1595 views)
Permalink

Re: IPV6 route registries [In reply to]

On 13/09/2011 17:03, Matthew Huff wrote:
> Given that we are a private org, and not an ISP, is there any place we should be registering our ASN/routes other than RADB for ipv6?

radb is appropriate for this, if you have a separate routing policy (i.e.
if you have your own ASN / address space).

Nick

jeroen at unfix

Sep 13, 2011, 9:19 AM

Post #3 of 19 (1593 views)
Permalink

Re: IPV6 route registries [In reply to]

On 2011-09-13 18:03 , Matthew Huff wrote:
> Given that we are a private org, and not an ISP, is there any place
> we should be registering our ASN/routes other than RADB for ipv6?

If you have IPv6 PI or PA space then your RIR already provides that
facility. Of course you can register ARIN space in the RIPE registry too
if wanted.

De-aggregating IPv6 PA blocks is heavily frowned upon, especially as it
quite destroys the whole idea of Provider Aggregated that the PA stands for.

Greets,
Jeroen

mhuff at ox

Sep 13, 2011, 9:24 AM

Post #4 of 19 (1596 views)
Permalink

RE: IPV6 route registries [In reply to]

This is PI space for BGP multihoming which we got from ARIN. Running with PA space never was an option.

> -----Original Message-----
> From: Jeroen Massar [mailto:jeroen [at] unfix]
> Sent: Tuesday, September 13, 2011 12:20 PM
> To: Matthew Huff
> Cc: 'ipv6-ops [at] lists'
> Subject: Re: IPV6 route registries
>
> On 2011-09-13 18:03 , Matthew Huff wrote:
> > Given that we are a private org, and not an ISP, is there any place
> > we should be registering our ASN/routes other than RADB for ipv6?
>
> If you have IPv6 PI or PA space then your RIR already provides that
> facility. Of course you can register ARIN space in the RIPE registry too
> if wanted.
>
> De-aggregating IPv6 PA blocks is heavily frowned upon, especially as it
> quite destroys the whole idea of Provider Aggregated that the PA stands for.
>
> Greets,
> Jeroen

jeroen at unfix

Sep 13, 2011, 9:29 AM

Post #5 of 19 (1608 views)
Permalink

Re: IPV6 route registries [In reply to]

On 2011-09-13 18:24 , Matthew Huff wrote:
> This is PI space for BGP multihoming which we got from ARIN. Running
> with PA space never was an option.

Awesome.

You should register your routes in as many places as possible, primary
candidates: ARIN RPSL[1], RIPE and RADB.

IMHO with the RIPE RR being the better location.

Greets,
Jeroen

[1] Yes, they have one, http://www.arin.net/resources/routing/
though I wonder how well used and up-to-date it really is.

drc at virtualized

Sep 13, 2011, 10:04 AM

Post #6 of 19 (1601 views)
Permalink

Re: IPV6 route registries [In reply to]

Hi,

On Sep 13, 2011, at 9:24 AM, Matthew Huff wrote:
> This is PI space for BGP multihoming which we got from ARIN. Running with PA space never was an option.

Out of curiosity, why wasn't PA an option?

Thanks,
-drc

Attachments:

signature.asc (0.44 KB)

nick at foobar

Sep 13, 2011, 10:42 AM

Post #7 of 19 (1594 views)
Permalink

Re: IPV6 route registries [In reply to]

On 13/09/2011 17:29, Jeroen Massar wrote:
> You should register your routes in as many places as possible, primary
> candidates: ARIN RPSL[1], RIPE and RADB.

no, don't. register in one place, and it will probably be propagated to
RADB anyway. Multiple registrations all over the place are the bane of
IRRDBs, because they end up giving inconsistent results when people
inevitably forget to update one, or the other.

Nick

mhuff at ox

Sep 13, 2011, 10:46 AM

Post #8 of 19 (1593 views)
Permalink

RE: IPV6 route registries [In reply to]

Both solutions can end up with inconsistencies. We have had providers update other registries as a proxy for us with only their info, creating problems.

> -----Original Message-----
> From: Nick Hilliard [mailto:nick [at] foobar]
> Sent: Tuesday, September 13, 2011 1:42 PM
> To: Jeroen Massar
> Cc: Matthew Huff; 'ipv6-ops [at] lists'
> Subject: Re: IPV6 route registries
>
> On 13/09/2011 17:29, Jeroen Massar wrote:
> > You should register your routes in as many places as possible, primary
> > candidates: ARIN RPSL[1], RIPE and RADB.
>
> no, don't. register in one place, and it will probably be propagated to
> RADB anyway. Multiple registrations all over the place are the bane of
> IRRDBs, because they end up giving inconsistent results when people
> inevitably forget to update one, or the other.
>
> Nick

jeroen at unfix

Sep 13, 2011, 11:05 AM

Post #9 of 19 (1595 views)
Permalink

Re: IPV6 route registries [In reply to]

On 2011-09-13 19:42 , Nick Hilliard wrote:
> On 13/09/2011 17:29, Jeroen Massar wrote:
>> You should register your routes in as many places as possible, primary
>> candidates: ARIN RPSL[1], RIPE and RADB.
>
> no, don't. register in one place, and it will probably be propagated to
> RADB anyway. Multiple registrations all over the place are the bane of
> IRRDBs, because they end up giving inconsistent results when people
> inevitably forget to update one, or the other.

Valid point. As such, I suggest to just stick to the RIPE IRR as it has
the most complete set of data and proper authorization rules in place
(yes, even for ARIN/APNIC/LACNIC/AFRINIC prefixes).

Greets,
Jeroen

nick at foobar

Sep 13, 2011, 1:12 PM

Post #10 of 19 (1589 views)
Permalink

Re: IPV6 route registries [In reply to]

On 13/09/2011 18:46, Matthew Huff wrote:
> Both solutions can end up with inconsistencies. We have had providers
> update other registries as a proxy for us with only their info, creating
> problems.

Every time a provider proxy-registers an irrdb object, god kills a kitten.

Nick

gert at space

Sep 13, 2011, 1:49 PM

Post #11 of 19 (1590 views)
Permalink

Re: IPV6 route registries [In reply to]

Hi,

On Tue, Sep 13, 2011 at 01:46:59PM -0400, Matthew Huff wrote:
> Both solutions can end up with inconsistencies. We have had providers update other registries as a proxy for us with only their info, creating problems.

Reasonable security at an IRRDB will prevent that.

IRRDBs that permit anyone to enter entries for other people's networks
should just go away, and not be used. This was a thing from last century,
when the Internet was a nice and cooperative place...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

mhuff at ox

Sep 13, 2011, 2:07 PM

Post #12 of 19 (1591 views)
Permalink

RE: IPV6 route registries [In reply to]

RADB allowed one of our ISPs to proxy add a route6 this week to our ASN. It's a pretty common thing at IRRs as of now. I assume it's because they believe most non-service providers are clueless...

> -----Original Message-----
> From: Gert Doering [mailto:gert [at] space]
> Sent: Tuesday, September 13, 2011 4:50 PM
> To: Matthew Huff
> Cc: 'Nick Hilliard'; 'Jeroen Massar'; 'ipv6-ops [at] lists'
> Subject: Re: IPV6 route registries
>
> Hi,
>
> On Tue, Sep 13, 2011 at 01:46:59PM -0400, Matthew Huff wrote:
> > Both solutions can end up with inconsistencies. We have had providers update other
> registries as a proxy for us with only their info, creating problems.
>
> Reasonable security at an IRRDB will prevent that.
>
> IRRDBs that permit anyone to enter entries for other people's networks
> should just go away, and not be used. This was a thing from last century,
> when the Internet was a nice and cooperative place...
>
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something today...?
>
> SpaceNet AG Vorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

gert at space

Sep 13, 2011, 11:13 PM

Post #13 of 19 (1585 views)
Permalink

Re: IPV6 route registries [In reply to]

Hi,

On Tue, Sep 13, 2011 at 05:07:54PM -0400, Matthew Huff wrote:
> RADB allowed one of our ISPs to proxy add a route6 this week to our ASN. It's a pretty common thing at IRRs as of now. I assume it's because they believe most non-service providers are clueless...

"a single IRR allowng this" is not "a pretty common thing at IRRs".

Actually I'm not sure whether *any* other IRR allows registration of
route/route6 objects without authentication by the address holder.

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

p.mayers at imperial

Sep 14, 2011, 4:05 AM

Post #14 of 19 (1587 views)
Permalink

Re: IPV6 route registries [In reply to]

On 13/09/11 18:04, David Conrad wrote:
> Hi,
>
> On Sep 13, 2011, at 9:24 AM, Matthew Huff wrote:
>> This is PI space for BGP multihoming which we got from ARIN. Running with PA space never was an option.
>
> Out of curiosity, why wasn't PA an option?

Because he wanted to do BGP multihoming to two different providers, I guess.

It's a real shame some clever mechanism to do that wasn't found *before*
we all started our rollouts / IPv4 ran out

<flameproof-suit mode="on" ;o>

jeroen at unfix

Sep 14, 2011, 4:16 AM

Post #15 of 19 (1589 views)
Permalink

Re: IPV6 route registries [In reply to]

On 2011-09-14 13:05 , Phil Mayers wrote:
> On 13/09/11 18:04, David Conrad wrote:
>> Hi,
>>
>> On Sep 13, 2011, at 9:24 AM, Matthew Huff wrote:
>>> This is PI space for BGP multihoming which we got from ARIN. Running
>>> with PA space never was an option.
>>
>> Out of curiosity, why wasn't PA an option?
>
> Because he wanted to do BGP multihoming to two different providers, I
> guess.
>
> It's a real shame some clever mechanism to do that wasn't found *before*
> we all started our rollouts / IPv4 ran out

For BGP Multihoming there is a solution, it is called BGP multihoming.

Now, for solving all kinds of other obstacles that come along with
multihoming there are also a variety of other solutions, all which get
discarded by people because what they know is this BGP-based multihoming
and thus that is all they want...

Greets,
Jeroen

mhuff at ox

Sep 14, 2011, 6:34 AM

Post #16 of 19 (1579 views)
Permalink

RE: IPV6 route registries [In reply to]

> Now, for solving all kinds of other obstacles that come along with
> multihoming there are also a variety of other solutions, all which get
> discarded by people because what they know is this BGP-based
> multihoming
> and thus that is all they want...
>

Or they have looked at so called other multihoming solutions found them incomplete or laughable. The ivory tower idea that a corporate entity would be able to globally renumber their prefixes every time some PHB switches providers is again laughable.

----
Matthew Huff | 1 Manhattanville Rd
Director of Operations | Purchase, NY 10577
OTA Management LLC | Phone: 914-460-4039
aim: matthewbhuff | Fax: 914-460-4139

> -----Original Message-----
> From: ipv6-ops-bounces+mhuff=ox.com [at] lists [mailto:ipv6-ops-
> bounces+mhuff=ox.com [at] lists] On Behalf Of Jeroen Massar
> Sent: Wednesday, September 14, 2011 7:17 AM
> To: Phil Mayers
> Cc: ipv6-ops [at] lists
> Subject: Re: IPV6 route registries
>
> On 2011-09-14 13:05 , Phil Mayers wrote:
> > On 13/09/11 18:04, David Conrad wrote:
> >> Hi,
> >>
> >> On Sep 13, 2011, at 9:24 AM, Matthew Huff wrote:
> >>> This is PI space for BGP multihoming which we got from ARIN.
> Running
> >>> with PA space never was an option.
> >>
> >> Out of curiosity, why wasn't PA an option?
> >
> > Because he wanted to do BGP multihoming to two different providers, I
> > guess.
> >
> > It's a real shame some clever mechanism to do that wasn't found
> *before*
> > we all started our rollouts / IPv4 ran out
>
> For BGP Multihoming there is a solution, it is called BGP multihoming.
>
>
> Now, for solving all kinds of other obstacles that come along with
> multihoming there are also a variety of other solutions, all which get
> discarded by people because what they know is this BGP-based
> multihoming
> and thus that is all they want...
>
> Greets,
> Jeroen

mtinka at globaltransit

Sep 14, 2011, 8:32 AM

Post #17 of 19 (1578 views)
Permalink

Re: IPV6 route registries [In reply to]

On Wednesday, September 14, 2011 12:03:08 AM Matthew Huff
wrote:

> Given that we are a private org, and not an ISP, is there
> any place we should be registering our ASN/routes other
> than RADB for ipv6?

We use RIPE.

Happy!

Mark.

Attachments:

signature.asc (0.82 KB)

brian.e.carpenter at gmail

Sep 14, 2011, 3:03 PM

Post #18 of 19 (1565 views)
Permalink

Re: IPV6 route registries [In reply to]

>> Now, for solving all kinds of other obstacles that come along with
>> multihoming there are also a variety of other solutions, all which get
>> discarded by people because what they know is this BGP-based
>> multihoming
>> and thus that is all they want...

Yes indeed, and of course this will work fine for a few tens of thousands
of multihomed sites. Where it will get us into very serious trouble is
if millions of smaller enterprises decide they want to pay extra for
multihoming. That's why people are still looking for alternatives.
IMNSHO this is *the* hardest problem in the Internet architecture.

> Or they have looked at so called other multihoming solutions found them incomplete or laughable. The ivory tower idea that a corporate entity would be able to globally renumber their prefixes every time some PHB switches providers is again laughable.

That is true today. However, note two points:

1. SOHO networks are a different matter and in effect get renumbered whenever
you restart the CPE box. There are features in IPv6 that make this easier,
because you can use the prefix from the ISP for external access and a ULA
prefix for internal devices that need static addresses. I think this will
become common practice once the next generation of CPEs appear (RFC 6204,
draft-ietf-v6ops-ipv6-cpe-router-bis).

2. For serious enterprise networks, renumbering still needs work (see RFC 5887).
That work is starting, please join in: http://datatracker.ietf.org/wg/6renum/charter/
The more operator input we have into that work, the better.

Brian

michael at rancid

Sep 14, 2011, 6:01 PM

Post #19 of 19 (1561 views)
Permalink

Re: IPV6 route registries [In reply to]

Hi Brian:

On 09/14/11 15:03, Brian E Carpenter wrote:

> 2. For serious enterprise networks, renumbering still needs work (see RFC 5887).
> That work is starting, please join in: http://datatracker.ietf.org/wg/6renum/charter/
> The more operator input we have into that work, the better.

I took a look a the 6RENUM charter. This "out-of-scope" part of the
charter bugs me a bit:

> 3. ISP renumbering; this is potentially the most complex renumbering
> case. However, more benefit can be achieved by focusing effort on site
> renumbering. The enterprise site analysis should include the ISP's role
> in the site's renumbering events.

A huge chunk of the IPv4 table bloat is not coming from end sites
announcing their multi-homed networks via BGP.[1,2] A lot of v4 table
bloat is caused by SPs that aren't able/willing to aggregate, either
because they got their fragmented prefixes over many years or they
acquired other providers and couldn't aggregate their prefixes (but
still wanted the address space).

So far, most of the IPv6 renumbering effort has focused on end-sites.
But in IPv4, there's a lot of theoretical ground to be gained by
renumbering service providers, *in addition to* end sites.

I can imagine end sites looking askance at SPs who appear to keep
focusing on site renumbering and ignoring the thorny, but important
issue of SP renumbering. As long as the costs appear skewed toward the
end-sites, even if they are low, you're not going to get a whole lot of
sites choosing end-site renumbering over BGP multihoming. That's partly
because the renumbering question only deals with the
renumbering-avoidance motivation for BGP multihoming; the 6RENUM WG
doesn't seem to delve into the fault-tolerance that is gained by the
instantaneous failover that BGP multihoming provides.

Looks like interesting work, though, and I will take a closer look.

michael*

*speaking for myself, noting that I currently work at an ISP.

[1] See http://www.cidr-report.org/
[2] RAS's presentation at NANOG 50 was pretty good at going through the
issues and not pointing (too many) fingers:
http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk49.Steenbergen.routingtable.pdf

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads