This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Those pesky ULAs again
- Previous message (by thread): [address-policy-wg] Those pesky ULAs again
- Next message (by thread): [address-policy-wg] Those pesky ULAs again
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Stephen Sprunk
stephen at sprunk.org
Tue May 29 04:42:46 CEST 2007
Thus spake "Roger Jørgensen" <roger at jorgensen.no> > On man, mai 28, 2007 14:30, Iljitsch van Beijnum wrote: >> On 27-mei-2007, at 22:51, Stephen Sprunk wrote: >>> The vast majority of folks will be fine with ULA-L >> >> Most people aren't very good with statistics, knowing for sure >> you have unique space is better than having just a 99.9999% >> probability that it's unique. > > not really, I work a place where we just can´t have any more > collision of address space, we have a few options and ULA- > central is the best. > > 1.) get ula-central and know for sure we won´t get into this > issue ever again. Unless the central administrator(s) screw up. The odds of that are non-zero, you know; in fact, as long as there's humans involved it's safe to say the odds are higher than a ULA-L collision. > 2.) administrate our own local version of ULA-central for > the organization we co-operate with Which is basically ULA-L, except that when someone new wants to join your private club, you'll need to spend a few seconds making sure they don't collide, and if they do (which is statistically unlikely, unless your club is on the scale of the public Internet) they'll need to renumber before they can join. > 3.) get RIR-space with all the add on administration and > documentation... The documentation is minimal unless you need a block larger than the minimum size, and the administration would be the same either way. > For me, only option 1.) is a real option, the other two are just > work-around since we don´t need global routing of the address > space in question. No, you've decided #1 is what you want, so you're downplaying its problems and potential harm to the community and criticizing all other options. >>> (or PA) space >> >> PA or PI is irrelevant to this discussion, people who need ULA >> may not even connect to the internet, and if they do, they need >> this space in ADDITION to routable address space, regardless >> of the type. > > this go for the type of organization I work for. We have our own > /32 already and it suite our need for public address space just > fine given the 3 options above. So why not carve out a /48, block it at your firewall to the public network, and get "local" addresses for free instead of paying for ULA-C? > ULA-central will satisfy a need for non-routable address space > that some bigger organization have. ULA-local are just a no go > even with a 99,99999% chance of no collision at all. Or to put it > in another context, renumbering or any change, experimentation > or downtime of the infrastructure are just not an option when > we´re talking about medicial/health related equipment. If you're in the medical field and your equipment can't withstand a few seconds of outage here and there (six nines = 31sec/yr downtime) without killing someone, you're going to have a lot of dead people on your hands. You and/or your vendors have failed. Networks have outages, period. In a typical network, most of them will be hardware-, circuit-, or design-related. I participated in a project for $BIG_TELCO and it took them several years of effort just to get from three nines to five nines consistently, and they never hit six nines. Nearly all of the remaining issues, when we were done, were due to humans making typos. If you think you're going to get to six (or more) nines of reliability, you're delusional in thinking that you're better at this than people literally throwing billions of dollars and thousands of engineers at the problem. Besides, renumbering should not cause any outages (at least more than what you normally see) unless your staff is incompetent. It's a lot of work, but it shouldn't cause an outage, much less death. >>> so the debate comes down to why we want to put orgs on >>> ULA-C space instead of just giving them PI space. >> >> No-brainer: ULA-C space doesn't use up routing table slots. > > see above, PI or PA have nothing todo in the discussion of > ULA-C or not. Yes, it does. If an org needs unique address space that will never appear in the DFZ, how does ULA-C meet their needs any better than PI? What is the purpose in creating yet another thing that needs to be registered when we already have two alternatives that fit every need I've seen proposed so far? > Site-local, the one that got deprecated would have suited OUR > (where I work) just fine but it isn´t there so we need a > replacement and ULA-C is what we would need. If SLAs would have worked for you, then you have no fundamental need for unique addresses and ULA-Ls are overkill, much less ULA-C. >>> If they're truly going to use it privately, they won't consume >>> routing slots in the DFZ, and if they aren't they'll be using PIv6 >>> anyways and won't have a need for ULA-C. >> >> You are being ridiculous. There is no connection between >> ULA-C and PI. Everyone can get ULA, not everyone can get PI. Anyone who is large enough to care about the extreme unlikelihood of collisions with ULA-L will be able to get PI, at least in ARIN's region. The bar is incredibly low; just about the only folks who don't qualify are people running home networks. And, for that matter, people can get a single PI block larger than /48, whereas someone who needs more than a /48 in ULA-C space would need multiple distinct blocks, presumably multiplying the fees to more than what PI costs. If your argument is that ULA-C will be cheaper, that is perhaps an argument that PI fees are too high -- not that anyone has stated if or how much cheaper ULA-C would be if it did pass. I have a hard time seeing anyone who has a legitimate need for ULA-C _or_ PI space whining about $100/yr. If they can't afford that, they can't afford anyone knowledgeable enough to care about the problems with ULA-L (or PA) space. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
- Previous message (by thread): [address-policy-wg] Those pesky ULAs again
- Next message (by thread): [address-policy-wg] Those pesky ULAs again
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]