Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

Re: [jump-admins] IPv6 multihoming

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


gert at space

Feb 8, 2011, 6:31 AM

Post #1 of 3 (583 views)
Permalink
Re: [jump-admins] IPv6 multihoming

Hi,

On Tue, Feb 08, 2011 at 09:34:31AM +0000, James A. T. Rice wrote:
> On Tue, 8 Feb 2011, Gert Doering wrote:
>
> >> No they don't, give them extra separate space.
> >
> > That's just playing pingpong with politics. "So the routing folks are
> > not able to come up with a recommendation, so we put the pressure on
> > the address policy group to come up with criteria who is allowed to
> > have a second slot in the routing table (and bonus addres space that
> > comes with it!) and who is not".
> >
> > This is the approach that hasn't worked for the last 10 years, which is
> > why the ball is in the operator's camp now.
>
> The reason it's not worked for the last 10 years is because if someone
> deaggregates their /16 into a bunch /24, it simply works. If we make sure
> it doesn't work, then they won't be able to do it.

I'm specifically talking about IPv6, not about IPv4. The address policy
community has not been able to come up with useful rules for this seemingly
simple question "who should be able to get a second routing table slot,
plus a big parcel of IPv6 addresses coming with it".

Besides that, it's not the address policy community's *job* to decide
about *routing table slots*. That's the routing operator community's
job, to agree upon "who can get what number of slots, for which price".

We (the address policy group) make sure they can get enough addresses
to number their customers and/or sites and/or networks. A small ISP
that has a /32 has all the addresses they ever need - but they might
need multiple routing table slots.

[..]
> PA is Provider Aggregatable. If a provider can't aggregate the block, make
> the policy be to give them another one.

I welcome a specific proposal that enables the RIR hostmasters to make
the decision, under which specific circumstances extra address blocks
should be handed out, and when not. What's been on the table so far
completely failed to be a) specific enough to be implementable, and
b) get consensus.

The easiest proposal would be "who asks for a second address block gets
another one", but for some funny reason, not many people seem to think
that this is a good idea.

Gert Doering
-- speaking as RIPE address policy wg chair
--
did you enable 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


james_r-ipv6ops at jump

Feb 8, 2011, 7:34 AM

Post #2 of 3 (559 views)
Permalink
Re: [jump-admins] IPv6 multihoming [In reply to]

On Tue, 8 Feb 2011, Gert Doering wrote:

> Besides that, it's not the address policy community's *job* to decide
> about *routing table slots*. That's the routing operator community's
> job, to agree upon "who can get what number of slots, for which price".

The two are intrinsically linked. The vast majority of operators are not
going to update their prefix filters continuously (other than for their
customers of course), thus if we end up in a situation where people are
forced to deaggregate their /32, we'll then end up in a situation where
people have to relax their prefix length filters across the whole board.

Being in a situation where the best way to avoid more specific hijacks of
your prefixes (eg recent China hijacks) is to announce the most specific
generally accepted prefixes yourself, stinks, we end up not only allowing
pointless deaggregation across the board, we almost require it so as to
make hijacks less painful. Lets not go there, just let operators filter on
/32 or /48 as appropriate, and allow people to get another /32 or /48 as
necessary when they can't aggregate.



> We (the address policy group) make sure they can get enough addresses
> to number their customers and/or sites and/or networks. A small ISP
> that has a /32 has all the addresses they ever need - but they might
> need multiple routing table slots.

Again, address policy and routing is intrincially linked, there's no point
playing politics of which working group should deal with this because in
the long run the suboptimal outcome is operators with orders of magnitude
more prefixes in the global tables because they either can't be bothered
to configure aggregation, or they want to go some way to protect
themselves from more specific hijackings. Once we end up in this
situation, just like the mess we have with v4 today, there is no going
back - we need to stop it from happening to begin with.


> I welcome a specific proposal that enables the RIR hostmasters to make
> the decision, under which specific circumstances extra address blocks
> should be handed out, and when not. What's been on the table so far
> completely failed to be a) specific enough to be implementable, and
> b) get consensus.

Fine, I propose that address policy should be such that if a party needs
an additional block for routing purposes, they should be given one.


> The easiest proposal would be "who asks for a second address block gets
> another one", but for some funny reason, not many people seem to think
> that this is a good idea.

I guess the tricky bit is about defining when they "need" one.


Typically this "need" is consistent with having an additional network,
autonomous (possibly not connected to) from the first, which they need to
announce some IP space from, generally they will then also have a seperate
autonomous system number for the additional site. In which case how about:

"Who asks for an additional block gets one, provided that they also meet
the requirements for additional autonomous system number under which
they will announce this additional prefix."

Regards
James


dr at cluenet

Feb 8, 2011, 11:31 AM

Post #3 of 3 (548 views)
Permalink
Re: [jump-admins] IPv6 multihoming [In reply to]

On Tue, Feb 08, 2011 at 03:34:55PM +0000, James A. T. Rice wrote:
> Typically this "need" is consistent with having an additional network,
> autonomous (possibly not connected to) from the first, which they need to
> announce some IP space from, generally they will then also have a seperate
> autonomous system number for the additional site.

I don't think so. My impression is that most "legit" "needs" are because of
inbound traffic engineering.

[.as always, "legit" and "need" is in the eye of the beholder]

> "Who asks for an additional block gets one, provided that they also meet
> the requirements for additional autonomous system number under which they
> will announce this additional prefix."

Doesn't really solve the traffic engineering problem.

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.