Mailing List Archive

On Mon, 2 May 2005, Daniel Roesen wrote:
> While you're updating your filters anyway, please revisit your decisions
> and consider using a "relaxed" version. For examples, see:

I guess there could be a middle ground for those who want a low(er)
maintenance version -- allow everything up to /32 or /35, and deny the
rest (except maybe the special microalloc block). ("Relaxed" allows
everything up to /48 which is quite a bit too relaxed for my taste at
least.)

That would encourage folks not to pollute the global routing table
with their more specifics.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Mon, May 02, 2005 at 01:06:55PM +0300, Pekka Savola wrote:
> On Mon, 2 May 2005, Daniel Roesen wrote:
> >While you're updating your filters anyway, please revisit your decisions
> >and consider using a "relaxed" version. For examples, see:
>
> I guess there could be a middle ground for those who want a low(er)
> maintenance version -- allow everything up to /32 or /35, and deny the
> rest (except maybe the special microalloc block). ("Relaxed" allows
> everything up to /48 which is quite a bit too relaxed for my taste at
> least.)

That would mean that:

- special exceptions for /48 microallocs have to be made

- poor man's multihoming (using more-specifics of PA aggregates) would
get hindered even more

- filters need updating again as soon as PI is finally being approved
by the ISP communities

> That would encourage folks not to pollute the global routing table
> with their more specifics.

In my book, enduser multihoming is no pollution but as valid use as any
ISP multihoming (PA agregates). I know you disagree, so we better leave
it at that. :-)

But I see the point that people are leaking more-specifics accidentally.
Those can be contacted and educated though. Not an easy task, granted.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 2-mei-2005, at 12:18, Daniel Roesen wrote:

>> I guess there could be a middle ground for those who want a low(er)
>> maintenance version -- allow everything up to /32 or /35, and deny
>> the
>> rest (except maybe the special microalloc block). ("Relaxed" allows
>> everything up to /48 which is quite a bit too relaxed for my taste at
>> least.)

[...]

>> That would encourage folks not to pollute the global routing table
>> with their more specifics.

> In my book, enduser multihoming is no pollution but as valid use as
> any
> ISP multihoming (PA agregates). I know you disagree, so we better
> leave
> it at that. :-)

I think it makes sense to differentiate between accepting /48s from
peers and accepting them from transits. I'd be happy to have a bunch
of /48s in my routing table that make traffic towards people within
the region flow more optimally, but I'm really not interested in /48s
from multiple timezones away.

On Mon, 2 May 2005, Daniel Roesen wrote:
>> That would encourage folks not to pollute the global routing table
>> with their more specifics.
>
> In my book, enduser multihoming is no pollution but as valid use as any
> ISP multihoming (PA agregates). I know you disagree, so we better leave
> it at that. :-)
>
> But I see the point that people are leaking more-specifics accidentally.
> Those can be contacted and educated though. Not an easy task, granted.

Yeah, but the key point is that "more specifics multihoming" is
in many cases more or less indistinguishable from acciental leaking,
traffic engineering for various (or no) reasons, and all the other
stuff that ends up in the routing tables.

Looking at how unsuccessful we've been at avoiding or cleaning swamps
in v4, it may be better to avoid going there with v6 in the first
place.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Hi,

| I think it makes sense to differentiate between accepting /48s from
| peers and accepting them from transits. I'd be happy to have a bunch
| of /48s in my routing table that make traffic towards people within
| the region flow more optimally, but I'm really not interested in /48s
| from multiple timezones away.
I agree.

--
---------- - - - - -+- - - - - ----------
Pim van Pelt Email: pim@ipng.nl
http://www.ipng.nl/ IPv6 Deployment
-----------------------------------------------

On Mon, May 02, 2005 at 01:59:10PM +0200, Iljitsch van Beijnum wrote:
> I think it makes sense to differentiate between accepting /48s from
> peers and accepting them from transits. I'd be happy to have a bunch
> of /48s in my routing table that make traffic towards people within
> the region flow more optimally, but I'm really not interested in /48s
> from multiple timezones away.

That works if your upstreams are regional tier3 ISPs, but most times
not with tier2 (as they are most often intercontinental) or above.

And doesn't work when the link between the /48 user and his uplink which
provides the IP space is down and you don't have the /48.

But all that is no news to anyone. :-)

So if you filter /48s from upstreams, you do degrade the multihomer to
singlehomer and just accept possible path optimizations (or DEgradations
actually).


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Mon, May 02, 2005 at 01:21:31PM +0300, Pekka Savola wrote:
> >But I see the point that people are leaking more-specifics accidentally.
> >Those can be contacted and educated though. Not an easy task, granted.
>
> Yeah, but the key point is that "more specifics multihoming" is
> in many cases more or less indistinguishable from acciental leaking,
> traffic engineering for various (or no) reasons, and all the other
> stuff that ends up in the routing tables.

Agreed, this is what I meant with "not an easy task" - not easy to
identify, not easy to remedy.

> Looking at how unsuccessful we've been at avoiding or cleaning swamps
> in v4, it may be better to avoid going there with v6 in the first
> place.

Yup, that's why we need a specific address range for PI, so people can
actually start filtering on minimum allocation boundaries if they really
desire without killing desperate pseudo-multihomers.

Until there is a clear picture where you can safely filter what, I'm
inclined to recommend to be liberal. What outdated, unmaintained
filters do to "unusual" legit prefixes can be seen every day. I still
find ASN filtering 2001:5000::/21 or others because of unmaintained
strict anti-bogon filters.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 2-mei-2005, at 14:26, Daniel Roesen wrote:

>> I think it makes sense to differentiate between accepting /48s from
>> peers and accepting them from transits. I'd be happy to have a bunch
>> of /48s in my routing table that make traffic towards people within
>> the region flow more optimally, but I'm really not interested in /48s
>> from multiple timezones away.

> That works if your upstreams are regional tier3 ISPs, but most times
> not with tier2 (as they are most often intercontinental) or above.

What doesn't work in this case?? I don't understand what you're saying.

> And doesn't work when the link between the /48 user and his uplink
> which
> provides the IP space is down and you don't have the /48.

That much is obvious.

Allowing all possible /48s out of all PA /32s and bigger just because
the /32 might be down is a very bad idea because not only are you
allowing unaggregatable PI (which is already very bad), but you're
also setting yourself up for very big problems when people accidently
deaggregate.

> But all that is no news to anyone. :-)

Right.

Anyone in Sweden for the big fight?

Hi,

On Mon, May 02, 2005 at 09:56:45AM +0200, Daniel Roesen wrote:
> please be reminded that RIPE recently did allocations outside of the
> "classic" 2001::/16:

*g* - you have seen a pre-view of my IPv6 talk, have you? This is one
of my major points on the "notable new allocations" slide - make sure
your BGP filters match reality...

> http://www.space.net/~gert/RIPE/ipv6-filters.html

This page needs work. It's on my TODO, but I have been distracted
lately... :-( - help welcome.

Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 71007 (66629)

SpaceNet AG Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234

Hi,

On Mon, May 02, 2005 at 01:59:10PM +0200, Iljitsch van Beijnum wrote:
> I think it makes sense to differentiate between accepting /48s from
> peers and accepting them from transits. I'd be happy to have a bunch
> of /48s in my routing table that make traffic towards people within
> the region flow more optimally, but I'm really not interested in /48s
> from multiple timezones away.

Which is why ICANN urgently needs to get their act together so you can
actually *see* where the netblock is coming from, without having to
main filters for hundreds of RIR blocks...

Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 71007 (66629)

SpaceNet AG Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234

On Mon, May 02, 2005 at 12:18:10PM +0200, Daniel Roesen wrote:

Hi,

> - special exceptions for /48 microallocs have to be made

why would this be a problem?

> - poor man's multihoming (using more-specifics of PA aggregates) would
> get hindered even more

Which is a good thing in my opinion. I want to be able to distinguish
between crap accidentally leaked and something which might be reasonable
announcement.

I might as well be killed for that idea, but I'd like to see a low-cost
small block IPv6 PI (/48 from a /something (/32?) reserved block) for
small charge (less than 200 EUR/year) to anyone who is requesting it.

It should be either charged from a supporting LIR or directly from the
owner with credit card (compare it to domains), but there should be no
discount as with the current RIPE score. If it isn't payed, it is
reclaimed. Still to see how to reclaim that space when the owner keeps
announcing it, but I think there are options (see bogon feeds for
example).

It would still force people doing reasonable ISP business to go for LIR
(/48 is too small if you want to give your customers "standard" network
size), it would still keep most kiddies with two IPv6-over-IPv4-over-
el-cheapo-DSL tunnels from doing multihoming just because it is l33t,
but it would allow small/medium companies or other entities where
renumbering is a hassle or real redundancy (with two physical lines) is
needed to use IPv6 as they do with IPv4 PI today.

I don't like this reflex heard often that the current model (pay for
LIR, then get IPv6 PA) is "money wins" (the often cited "pay to play").
Every additional prefix out there (doesn't matter if we are at 600
prefixes like today in IPv6, or 160000 as in IPv4) is an additional
burden on the routing structure. I don't like this to become free,
especially since you can today pollute IPv4 BGP with some thousand
prefixes even on an old and rusty 2500, as long as you don't import your
upstreams fulltable. Paying for it makes the people think about whether
they need it in the first place, and to return it if it is no longer
needed. You shouldn't get such a resource if you are just to lazy to
renumber ten office workstations and two servers once a year or because
you like being bleeding edge with your network setup.

> - filters need updating again as soon as PI is finally being approved
> by the ISP communities

You cannot run an AS on autopilot. The few ones doing that are mostly
old 6bone tunneled ASNs where the tunnel router has been lost somewhere
in the raised floor. I don't consider that a problem.

> But I see the point that people are leaking more-specifics accidentally.
> Those can be contacted and educated though. Not an easy task, granted.

Good luck when IPv6 starts to fly and has several thousand prefixes in
the DFZ :-)

Bernhard, waiting for the flamewar to start
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050502/a295e3a4/attachment-0001.bin

On 2-mei-2005, at 14:59, Gert Doering wrote:

>> but I'm really not interested in /48s from multiple timezones away.

> Which is why ICANN urgently needs to get their act together so you can
> actually *see* where the netblock is coming from, without having to
> main filters for hundreds of RIR blocks...

Like that's going to help: the RIPE region spans from Vladivostok
(+10) to Greenland (-3), that's two thirds of all timezones.

If you want to filter on geography, you have to do it right. :-)

Hi,

On Mon, May 02, 2005 at 03:14:09PM +0200, Iljitsch van Beijnum wrote:
> If you want to filter on geography, you have to do it right. :-)

Small steps first...

Gert Doering
-- NetMaster
--
Total number of prefixes smaller than registry allocations: 71007 (66629)

SpaceNet AG Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
D- 80807 Muenchen Fax : +49-89-32356-234

On 2 May 2005, at 08:05, Pim van Pelt wrote:

> Hi,
>
> | I think it makes sense to differentiate between accepting /48s from
> | peers and accepting them from transits. I'd be happy to have a bunch
> | of /48s in my routing table that make traffic towards people within
> | the region flow more optimally, but I'm really not interested in /48s
> | from multiple timezones away.
> I agree.

To pick a "/48s are bad" advocate at random, the following are examples
of legitimate /48 advertisements from ARIN space that you might
consider permitting:

2001:500::/48 -- F root nameserver
2001:500:1::/48 -- H root nameserver
2001:500:2::/48 -- C root nameserver
2001:500:3::/48 -- L root nameserver

The other RIRs also have policies which allow them to assign PI /48s
for critical infrastructure (not just exchange points).

I realise that most people in this thread are probably aware of these
micro-allocations, but to the casual observer that may not be obvious.
So, for the record, some /48s are good :-)


Joe

On Mon, May 02, 2005 at 02:53:13PM +0200, Iljitsch van Beijnum wrote:
> >That works if your upstreams are regional tier3 ISPs, but most times
> >not with tier2 (as they are most often intercontinental) or above.
>
> What doesn't work in this case?? I don't understand what you're
> saying.

Your AMSIX peer may well have multihomed direct customers in Asia.
So you will receive them. Ergo you have to filter again if you don't
want to see those "far away" by prefix classification (RIR ranges).
You already entered into that discussion with Bernhard.

> Allowing all possible /48s out of all PA /32s and bigger just because
> the /32 might be down is a very bad idea because not only are you
> allowing unaggregatable PI (which is already very bad), but you're
> also setting yourself up for very big problems when people accidently
> deaggregate.

So we can agree that this kind of multihoming is wrong for two reasons:
it still keeps you hostage to one ISP and it cannot be filtered sanely
to make it work in all cases. ACK?

At least the second thing is an operational matter, so it's not totally
off-topic here. .-) But we still should avoid "The Great Multihoming
debate" here as far as possible. :-)

> Anyone in Sweden for the big fight?

NAK. Noone there to pay for the fun. Will probably stop by next
Amsterdam meeting.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Hey Joe,

On Mon, May 02, 2005 at 11:05:16AM -0400, Joe Abley wrote:
> To pick a "/48s are bad" advocate at random, the following are examples
> of legitimate /48 advertisements from ARIN space that you might
> consider permitting:
>
> 2001:500::/48 -- F root nameserver
> 2001:500:1::/48 -- H root nameserver
> 2001:500:2::/48 -- C root nameserver
> 2001:500:3::/48 -- L root nameserver

Hm, I cannot see the last two anywhere floating around. Are they
supposed to be visible currently?

http://www.sixxs.net/tools/grh/lg/?prefix=2001:500:2::/48
http://www.sixxs.net/tools/grh/lg/?prefix=2001:500:3::/48

Nor on route-views3.routeviews.org


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Mon, 2 May 2005, Daniel Roesen wrote:
> On Mon, May 02, 2005 at 11:05:16AM -0400, Joe Abley wrote:
>> To pick a "/48s are bad" advocate at random, the following are examples
>> of legitimate /48 advertisements from ARIN space that you might
>> consider permitting:
>>
>> 2001:500::/48 -- F root nameserver
>> 2001:500:1::/48 -- H root nameserver
>> 2001:500:2::/48 -- C root nameserver
>> 2001:500:3::/48 -- L root nameserver
>
> Hm, I cannot see the last two anywhere floating around. Are they
> supposed to be visible currently?

Nor do I see any of these at the Federal GigaPOP, AS 2884.

Perhaps my upstream network is aggressively filtering /48's ....

wfms

Daniel Roesen wrote:
> While you're updating your filters anyway, please revisit your
> decisions and consider using a "relaxed" version. For examples, see:
>
> http://www.space.net/~gert/RIPE/ipv6-filters.html

The strict filters on that page haven't been updated yet.

Here's an updated 'strict' filter:

ipv6 prefix-list strict seq 5 deny 2001:db8::/32 le 128
ipv6 prefix-list strict seq 10 permit 2001::/21 ge 35 le 35
ipv6 prefix-list strict seq 15 permit 2001:500::/30 ge 48 le 48
ipv6 prefix-list strict seq 20 permit 2001::/16 ge 19 le 32
ipv6 prefix-list strict seq 25 permit 2002::/16
ipv6 prefix-list strict seq 30 permit 2003::/16 ge 19 le 32
ipv6 prefix-list strict seq 35 permit 2600::/22 ge 23 le 32
ipv6 prefix-list strict seq 40 permit 2604::/22 ge 23 le 32
ipv6 prefix-list strict seq 45 permit 2608::/22 ge 23 le 32
ipv6 prefix-list strict seq 50 permit 260c::/22 ge 23 le 32
ipv6 prefix-list strict seq 55 permit 2a00::/21 ge 22 le 32
ipv6 prefix-list strict seq 60 permit 3ffe::/18 ge 24 le 24
ipv6 prefix-list strict seq 65 permit 3ffe:4000::/18 ge 32 le 32
ipv6 prefix-list strict seq 70 permit 3ffe:8000::/22 ge 28 le 28
ipv6 prefix-list strict seq 75 deny ::/0 le 128

which is also a little more strict on /35's.

- Kevin

On Mon, May 02, 2005 at 11:49:18AM -0400, William F. Maton Sotomayor wrote:
> On Mon, 2 May 2005, Daniel Roesen wrote:
> >On Mon, May 02, 2005 at 11:05:16AM -0400, Joe Abley wrote:
> >>To pick a "/48s are bad" advocate at random, the following are examples
> >>of legitimate /48 advertisements from ARIN space that you might
> >>consider permitting:
> >>
> >>2001:500::/48 -- F root nameserver
> >>2001:500:1::/48 -- H root nameserver
> >>2001:500:2::/48 -- C root nameserver
> >>2001:500:3::/48 -- L root nameserver
> >
> >Hm, I cannot see the last two anywhere floating around. Are they
> >supposed to be visible currently?
>
> Nor do I see any of these at the Federal GigaPOP, AS 2884.
>
> Perhaps my upstream network is aggressively filtering /48's ....
>
> wfms

Nah, your upstream is probably fine. Appears last two are not advertised
to GRT at this time.

I can't see here either , while we are surely accepting /48s from
2001:500::/30 space :)

FYI, these are the only two prefixes I see under 2001:500::/32 scope:

Network Next Hop Metric LocPrf Weight Path
* 2001:500::/48 2001:418:0:4000::11
0 200 0 2914 3557 i
* 2001:5014:100:1::1
200 0 1273 3557 i
*>i 2001:4f8:4:b:290:6900:b30:541f
0 200 0 3557 i
*> 2001:500:1::/48 2001:5014:100:1::1
110 0 1273 11537 668 13 i


--
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
james@towardex.com | www.towardex.com