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/[email protected]/
[address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
- Previous message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
- Next message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jørgen Hovland
jorgen at hovland.cx
Mon Nov 14 10:51:58 CET 2005
-----Original Message----- From: Elmar K. Bins [mailto:elmi at 4ever.de] > Hello Jørgen, Hello >> Will it not satisfy your needs placing 200 servers at 100 (numbers randomly >> selected) MCI locations world wide using IP space assigned by MCIs /32? > >Certainly not - why should one be satisfied with such a pseudo-solution? Because that’s what everybody else are doing? That’s why we currently have 600 routes in dfz and not one per server on the internet? Should DNS be excused only because the protocol itself supports a finite amount of IP addresses? >A service provider (we _are_ talking about Internet infrastructure service >providers currently, keep that in mind) that has come to the conclusion >they want to "anycast" (aka shared unicast) their services, surely has >thought about going to a big ISP before and decided that that' not what >they want. Ok, but I would still like to hear from people who have tried that but had to reject the solution for valid reasons where the ISP offered you this service. Anyone? >> Either way, there is no difference here network wise? You get >> exactly the same reachability/redundancy. > >Only if you limit your thoughts to a very small world. Sorry, but >the fallacy of your argument is so obvious that the words fail me here. Could you be more specific? I am sure there are ISPs that are not willing to sell anycast services, but if you have buyers then the sellers will always show up eventually. >> I am against a policy that would let LIRs receive prefixes from RIRs when >> the intention is to use the prefix for anycast. I have hopefully shown that >> you don't need a dedicated prefix for that. > > No. You have shown that _you_ don't need that. Obviously some people have different needs. It is good that we try to figure those out. > You try to decide here how > other people run their services. No, I am trying to prevent excessive defragmentation of the routing table. I am trying to prevent a special case of PI where you are not even required to have your own network. The requirement to this special PI case is so low that anyone would be able to apply for it - and anyone _will_ apply for it. In order to prevent that we only permit DNS? Are there any other services that should be permitted? > I honestly believe that's none of your > business, but up to the respective service provider. You can give them > good advice, of course. But you must be open to accepting arguments for > the way they intend to do it. So far we have two reasons why anycast prefixes, "anycast PI", should be permitted: * Bankruptcy * Routing policies >> Nameservers are not the only >> anycast service so it would be tricky to discuss this in general. > >DNS is a special service (UDP packet size stuff) and needs a special >solution - unfortunately. I disagree. DNS is certainly not a special service. The importance of it is however perhaps greater than many others - many, but far from all. The packet size thing is a general design problem. As far as I know, there are currently two methods to solve it: * EDNS0 * TC flag If you are going to use the packet size problem as an argument to use anycast, then I think it would be a good idea to hear reasons why none of these solutions would be suitable (also because I don't really know it myself) and perhaps if there are any other solutions that would help solving the problem? > >From that perspective I seem to see 2 aspects in the recent discussion: > > > >- you shall not receive address space for builing a service, you are to > > buy that from some "big-folk". > > > > This is an intersting point of view, and taken to the extreme will > > make us end up with a _very small_ number of _very big_ entities. > > > > Traditionally these things were called monopolies. Nothing I would be > > too happy to see coming back ;-) > > You did not comment on this part. Why? I was probably just a bit unclear. "All you need to do is to create a network and ask for address space.." There is no monopoly threat as long as you follow the requirements. If the requirements are too strict, then it would become a problem. Currently, I think they are not. Joergen Hovland
- Previous message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
- Next message (by thread): [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]