RE: [lir-wg] Discussion about RIPE-261
Gert,
Gert Doering wrote: The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate).
This does _not_ work in at least two cases: - If someone implements RPF checks and someone else filters. - If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks. Please look at the following (4 slides, very short) http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt Then come back to me and tell me that PA holes and filtering work together. The slides should be self-explanatory but they were designed for live presentation. I do welcome questions. Michel.
hi, On Tue, May 27, 2003 at 01:14:27PM -0700, Michel Py wrote:
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate).
This does _not_ work in at least two cases:
- If someone implements RPF checks and someone else filters.
Strict RPF check will break as soon as you have asymmetric routing, which you usually can't avoid if you filter on upstream/peering lines. So doing that in the first place is a bad idea. The RPF filter belongs on the customer line (and will not hurt in this case).
- If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks.
If the ISP dies hard enough so that their prefix will disappear, they won't be visible to people that filter on /32 boundaries and have no fallback default route to one of their upstreams. But so what. If one of their upstream ISPs messes up seriously enough, they can always hurt their downstream customers' routing (by announcing the prefix and then blackholing internally, for example).
Please look at the following (4 slides, very short) http://arneill-py.sacramento.ca.us/ipv6mh/pa_holes.ppt Then come back to me and tell me that PA holes and filtering work together. The slides should be self-explanatory but they were designed for live presentation. I do welcome questions.
Can't check those slides right now, now proprietary-file-format-viewer available, sorry. Will check tomorrow. But besides your slides, experience from "what's out there" (in IPv4 land) shows that the concept of PA holes works pretty well - for certain kinds of problems. It's not a panacea, but neither is any other approach. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Tue, May 27, 2003 at 11:32:39PM +0200, Gert Doering wrote:
If the ISP dies hard enough so that their prefix will disappear, they won't be visible to people that filter on /32 boundaries and have no fallback default route to one of their upstreams.
But so what. If one of their upstream ISPs messes up seriously enough, they can always hurt their downstream customers' routing (by announcing the prefix and then blackholing internally, for example).
(short, that's not how stuff works) Again, I thought the point was making commercial IPv6 multihoming work. This is all fine and dandy on 6bone but my clients will not pay me for a backup link that won't work when the primary provider goes down. No pay, no multihoming. No multihoming no commercial offering. No commercial offering, no happy fun end-to-end IPv6. Game set and match. (and yes, this is even more true for hosting than home users)
Total number of prefixes smaller than registry allocations: 54837 (54495)
I'm sorry, you were talking about PA holes ? cheers -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
The *benefit* of "/48 multihoming" is that you can filter those routes if you don't want to see them - then your routers will send packets down the /32 road, and eventually hit a router that knows about the /48 (which is why I consider this approach superior to "everybody gets a independent prefix", which I can't properly aggregate).
This does _not_ work in at least two cases:
- If someone implements RPF checks and someone else filters.
RPF will most likely break with most of the proposed multi6 solutions.
- If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks.
You mean if /48s where filtered? So don't filter ;-) That was the original idea with the proposal... - kurtis -
On Thu, May 29, 2003 at 09:07:35AM +0200, Kurt Erik Lindqvist wrote:
- If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks.
You mean if /48s where filtered? So don't filter ;-) That was the original idea with the proposal...
You mean, ask google.com upstream provider to not filter you ? Or your provider's provider to not filter google ? :) -- Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594 GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B 599D 93A1 A3FB 75E4 51E2 The views expressed above do not bind my employer.
- If the primary ISP (the one that announces the /32) dies. The site is dead as well. This is the #1 reason why organizations do multihome: they want to be up even if their primary ISP tanks.
You mean if /48s where filtered? So don't filter ;-) That was the original idea with the proposal...
You mean, ask google.com upstream provider to not filter you ? Or your provider's provider to not filter google ? :)
Well, the entire idea was to filter at /48s. If you filter on shorter prefixes, the idea fails. Simple. - kurtis -
participants (4)
-
Carlos Morgado -
Gert Doering -
Kurt Erik Lindqvist -
Michel Py