Re: [ipv6-wg@ripe.net] IPv6 access to K-root
On 2-aug-04, at 19:42, Andrei Robachevsky wrote:
K-root server has now IPv6 transport enabled.
k.root-servers.net. AAAA 2001:7fd::1 A 193.0.14.129
This information is also available from www.root-servers.org webiste.
Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out: inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary. Iljitsch van Beijnum
iljitsch@muada.com (Iljitsch van Beijnum) wrote:
This information is also available from www.root-servers.org webiste.
Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out:
inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net
I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.
So do I, since I have a ccTLD service to provision with IPv6. Elmar. (And yes, ARIN sent me to RIPE, and they sent me home...) -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hi, On Thu, Feb 24, 2005 at 08:02:55PM +0100, Elmar K. Bins wrote:
So do I, since I have a ccTLD service to provision with IPv6.
As you know, everybody is special, but the *only* thing that cannot be resolved by DNS is the IPv4/IPv6 address of root name servers. There is no special case policy for (unicast) ccTLD name servers, for major search engines, big software vendor download sites, etc. -> find an upstream provider, get an IPv6 address block, and enter that in the relevant DNS zones. Of course the underlying question returns to "how to do IPv6 multihoming for A Special End Site". 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
gert@space.net (Gert Doering) wrote:
There is no special case policy for (unicast) ccTLD name servers, for major search engines, big software vendor download sites, etc. -> find an upstream provider, get an IPv6 address block, and enter that in the relevant DNS zones.
I'm not talking unicast, I'm talking of not having a chance to get an assignment for ccTLD DNS servers. And yes, they would be anycast, for packet size reasons (even if that isn't the issue here; count the Verisign special assignments). Our home v6 network is a PA /48 (you of all should know) which I cannot properly multihome. Fortunately, that's not a problem, even if some people are filtering it. The real problem is DNS deployment in v6. v4 has 11 (14 by June) of our servers, spread world-wide; I'd like to do the same with v6 servers, but I simply can't. Every f***ing registry on the planet has the special assignment policy (with very strict rules, mind you), except for the one they always send me back to ("sorry, not our business, you're in the RIPE region").
Of course the underlying question returns to "how to do IPv6 multihoming for A Special End Site".
I know, and I am getting sick of the process not getting one step further. I don't know where the problem really is, but the only way to get one or a couple /48s for anycasting seems to open business in the USA. Or Zaire. Or New Zealand. So one of the registries that long have this kind of policy consider me their business. I don't know why the RIPE community doesn't even publish the papers that are being circulated and have been for over a year now. Is everybody busy waiting for the IETF v6-multihoming group to come to a conclusion? Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 25-feb-05, at 0:02, Elmar K. Bins wrote:
The real problem is DNS deployment in v6. v4 has 11 (14 by June) of our servers, spread world-wide; I'd like to do the same with v6 servers, but I simply can't.
Every f***ing registry on the planet has the special assignment policy (with very strict rules, mind you), except for the one they always send me back to ("sorry, not our business, you're in the RIPE region").
Well, there are more than a hundred TLDs and if they all want 11 IPv6 prefixes that would inflate the v6 table by more than 150%. I think a reasonable proposal from a good portion of the TLD community would go a long way, though.
Of course the underlying question returns to "how to do IPv6 multihoming for A Special End Site".
Everyone thinks they're special. That's how you get large routing tables. (It's not _that_ long ago that the root servers got their addresses from the organizations that hosted them.)
Is everybody busy waiting for the IETF v6-multihoming group to come to a conclusion?
In that case you won't have to wait much longer as this is going to happen within a few weeks. However, the multi6 mechanisms (that still have to be developed) aren't very suitable for multihoming DNS service.
iljitsch@muada.com (Iljitsch van Beijnum) wrote:
Well, there are more than a hundred TLDs and if they all want 11 IPv6 prefixes that would inflate the v6 table by more than 150%.
There are ways around this, and people are pretty reasonable. I believe in other ccTLDs as well as in ours people know pretty well what they are doing and what they should demand. Actually, what would keep them from doing things together again for a try? Anyway, v6 space is organized quite different from v4 space (let's hope it's not becoming overorganized in the near future), and, while you're right and the prefix tables will grow, they will not hit the same technological boundaries v4 hit all the while. Even if the table grows from the handful of prefixes (who sees more than 2000?) to half a million, the then-current routers will easily cope with that. And will 1100 prefixes (I'd expect around 300, mind) make any difference?
Everyone thinks they're special. That's how you get large routing tables.
Who gets to decide? We're talking infrastructure here. ARIN seems to have a picture of specialness quite different from RIPE's view. If you ask me, it's closer to what's needed. And I cannot see the v6 train pulling out of the yard before the infrastructure all people are accustomed to does speak IPv6. And I mean: In the way it speaks v4, not in a lab environment or in mini- scale. In real life some things are more special than others.
Is everybody busy waiting for the IETF v6-multihoming group to come to a conclusion?
In that case you won't have to wait much longer as this is going to happen within a few weeks. However, the multi6 mechanisms (that still have to be developed) aren't very suitable for multihoming DNS service.
I'm following the list, and, as well as a lot of people have worked on proposals and design papers, I believe the whole thing is far from deployment. But that's my $0.02. I have to find solutions now. I could long ago have convinced my superiors to open a branch office in $ELSEWHERE and go to the appropriate RIR, but I have always been a friend and promoter of the "RIPE way of doing things", and I would rather see the RIPE community get out of the ivory tower and into the real world, where some things _are_ special. Alright, I'm repeating myself. Maybe we can restart the discussion that faded away after 2003, and get things on the right track. Which of course means, afterwards all people share my opinion. :-) Elmar.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Elmar, On Feb 25, 2005, at 1:02 AM, Elmar K. Bins wrote:
Everyone thinks they're special. That's how you get large routing tables.
Who gets to decide? We're talking infrastructure here.
ARIN seems to have a picture of specialness quite different from RIPE's view. If you ask me, it's closer to what's needed.
And I cannot see the v6 train pulling out of the yard before the infrastructure all people are accustomed to does speak IPv6. And I mean: In the way it speaks v4, not in a lab environment or in mini- scale. In real life some things are more special than others.
At the same time there are ccTLDs who are already running their slaves on IPv6.... -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQh9i3aarNKXTPFCVEQI1SgCgu62f9KGM533PZe21vN4mFU0AqcUAoOm8 uesgJeVD4WOeKagJ70W67Z7v =JRIm -----END PGP SIGNATURE-----
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
And I cannot see the v6 train pulling out of the yard before the infrastructure all people are accustomed to does speak IPv6. And I mean: In the way it speaks v4, not in a lab environment or in mini- scale. In real life some things are more special than others.
At the same time there are ccTLDs who are already running their slaves on IPv6....
Oh, we certainly are. Two sets on two v6 addresses I cannot anycast, since they are somebody else's PA. Contrast this with eleven/fifteen v4 sets on five unicast (provider PA) and one anycast v4 (PI) address. Like Nils said, that's not real business, it's not even a start. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 20:03, Elmar K. Bins wrote:
Contrast this with eleven/fifteen v4 sets on five unicast (provider PA) and one anycast v4 (PI) address.
So what you are _really_ arguing (or should be) is that you can get PA IPv4 but does not qualify for PA IPv6. That is something completely different, and I think we more or less have agreed in the RIPE region that this difference needs to be fixed... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDMTaarNKXTPFCVEQKV3ACgrjygZtuNmsMEvmkKr3C5tBDI/AUAnjAc eiqoDFUmFetqUbcu3+mwMInk =DEFZ -----END PGP SIGNATURE-----
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
Contrast this with eleven/fifteen v4 sets on five unicast (provider PA) and one anycast v4 (PI) address.
So what you are _really_ arguing (or should be) is that you can get PA IPv4 but does not qualify for PA IPv6. That is something completely
We're a LIR, so naturally (!) we have our v4 PA. Funny enough, a v6 PA seems out of the question. Were this an ordinary end-site, I'd have no problem with it; unfortunately, I have to overcome a few things which includes rolling out a heap of name servers. As Iljitsch said, DNS has built-in redundancy. Unfortunately, it's still limited. The biggest obstacle is the 510-byte answer packet that can only be circumvented by anycasting the stuff (which of course is impossible with a PA assignment). The next biggest obstacle, of course, is that some people simply refuse to listen. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hi, On Mon, Feb 28, 2005 at 10:11:27AM +0100, Elmar K. Bins wrote:
Were this an ordinary end-site, I'd have no problem with it; unfortunately, I have to overcome a few things which includes rolling out a heap of name servers. As Iljitsch said, DNS has built-in redundancy. Unfortunately, it's still limited. The biggest obstacle is the 510-byte answer packet that can only be circumvented by anycasting the stuff (which of course is impossible with a PA assignment).
This is supposed to be fixed by the "anycast policy proposal", which is in the works (proposed by Andreas Baess, and being delayed since months because Andreas was distracted by things like IDN domains). Please don't intermix "generic PI to end-users", "IPv6 multihoming", "critical infrastructure" and "ancast address space" issues - it will just create a very blurred picture, where everybody is argueing about something else. 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
gert@space.net (Gert Doering) wrote:
This is supposed to be fixed by the "anycast policy proposal", which is in the works (proposed by Andreas Baess, and being delayed since months because Andreas was distracted by things like IDN domains).
So it's inhouse. Unfortunately, Andreas is on holiday, but I am confident he'll push this forward as soon as he's back. I was under the wrong assumption, the paper had already been submitted...
Please don't intermix "generic PI to end-users", "IPv6 multihoming", "critical infrastructure" and "ancast address space" issues - it will just create a very blurred picture, where everybody is argueing about something else.
Well, this is a v6 multihoming, critical (isn't everybody?), anycasting end-user... it actually _is_ intermixed and blurry. Oh, and regarding Iljitsch: The root/*tld server operators unfortunately can't force anyone to use EDNS0 compatible software. In theory, everything's simple. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On 28-feb-05, at 11:37, Elmar K. Bins wrote:
Oh, and regarding Iljitsch: The root/*tld server operators unfortunately can't force anyone to use EDNS0 compatible software. In theory, everything's simple.
I think the intersection between the group that doesn't use EDNS0 and the group that supports IPv6 is negligible. And it any event, dropping IPv6 glue addresses from the response is hardly deadly. I can understand why the root people are somewhat concerned about the boot strapping thing, but for TLDs this isn't an issue.
iljitsch@muada.com (Iljitsch van Beijnum) wrote:
Oh, and regarding Iljitsch: The root/*tld server operators unfortunately can't force anyone to use EDNS0 compatible software. In theory, everything's simple.
I think the intersection between the group that doesn't use EDNS0 and the group that supports IPv6 is negligible. And it any event, dropping IPv6 glue addresses from the response is hardly deadly. I can understand why the root people are somewhat concerned about the boot strapping thing, but for TLDs this isn't an issue.
I'll leave this part to Peter, since I'm not sure how to care for dropping the "correct" parts - I still believe we'll have to make sure the full set gets through to the requestor, and the dropping occurs there. And then you're again stuck with your 510 Byte limit. Unless...unless of course you can influence the order in which your $DNS_SOFTWARE outputs the records. Alas, I'm not comfortable with dropped content, so I favour the "smaller packet" approach. Anyway, Peter's turn :-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Thursday 24 February 2005 23:36, Iljitsch van Beijnum wrote:
On 25-feb-05, at 0:02, Elmar K. Bins wrote:
The real problem is DNS deployment in v6. v4 has 11 (14 by June) of our servers, spread world-wide; I'd like to do the same with v6 servers, but I simply can't.
Every f***ing registry on the planet has the special assignment policy (with very strict rules, mind you), except for the one they always send me back to ("sorry, not our business, you're in the RIPE region").
Well, there are more than a hundred TLDs and if they all want 11 IPv6 prefixes that would inflate the v6 table by more than 150%.
I think a reasonable proposal from a good portion of the TLD community would go a long way, though.
Of course the underlying question returns to "how to do IPv6 multihoming for A Special End Site".
Everyone thinks they're special. That's how you get large routing tables.
yep - I'm special :). But the roots are more special. I want multihoming, until then v6 will NOT go mainstream. However, the roots really are a special case - There's no reason (at least none I can think of) why all the root's in the world couldn't be hosted out of a single /48, or rather a /48 for each region - which would avoid my nightmare of a single entity being able to control major internet resources.
(It's not _that_ long ago that the root servers got their addresses from the organizations that hosted them.)
and it's not that long ago that my laptop would have taken up your entire house - you point is ?
Is everybody busy waiting for the IETF v6-multihoming group to come to a conclusion?
In that case you won't have to wait much longer as this is going to happen within a few weeks. However, the multi6 mechanisms (that still have to be developed) aren't very suitable for multihoming DNS service.
Be interesting to see what they come back with. How can multihoming be suitable to one kind of service and not another - I'll wait 'til they publish they're docs, you can explain then Iljitsch :) (unless we're talking locators again). As I said above, the roots are a special case - end of story - we cannot live without them (slight exaggeration). Why can't a /48 be set a side for the root servers in each region (or even a global /32). Jon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 1:23 AM, Jon Lawrence wrote:
On Thursday 24 February 2005 23:36, Iljitsch van Beijnum wrote:
On 25-feb-05, at 0:02, Elmar K. Bins wrote: Everyone thinks they're special. That's how you get large routing tables.
yep - I'm special :). But the roots are more special. I want multihoming, until then v6 will NOT go mainstream. However, the roots really are a special case - There's no reason (at least none I can think of) why all the root's in the world couldn't be hosted out of a single /48, or rather a /48 for each region - which would avoid my nightmare of a single entity being able to control major internet resources.
Which single entity? And what would a single /48 give you? The above makes no sense to me. I think you need to add more text.
Is everybody busy waiting for the IETF v6-multihoming group to come to a conclusion?
In that case you won't have to wait much longer as this is going to happen within a few weeks. However, the multi6 mechanisms (that still have to be developed) aren't very suitable for multihoming DNS service.
Be interesting to see what they come back with. How can multihoming be suitable to one kind of service and not another - I'll wait 'til they publish they're docs, you can explain then Iljitsch :) (unless we're talking locators again).
Documents are published. Protocol work will be done in new WG. Architecture published. Multi6 is closing in two weeks. Yes, there will be identifiers and locators. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQh9YGaarNKXTPFCVEQJzPgCg9oSbuFpfBsoxA4h/gWsNbN1vSVwAnR7j VipmsHiLNT0xpitAnghf7X0K =Sjhv -----END PGP SIGNATURE-----
On Fri, 2005-02-25 at 17:53 +0100, Kurt Erik Lindqvist wrote:
On Feb 25, 2005, at 1:23 AM, Jon Lawrence wrote:
Be interesting to see what they come back with. How can multihoming be suitable to one kind of service and not another - I'll wait 'til they publish they're docs, you can explain then Iljitsch :) (unless we're talking locators again).
Documents are published. Protocol work will be done in new WG. Architecture published. Multi6 is closing in two weeks. Yes, there will be identifiers and locators.
Shibby... eehmm Shim6 that is ;) Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32.... Greets, Jeroen
On Fri, Feb 25, 2005 at 07:00:27PM +0100, Jeroen Massar wrote:
Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32....
And now the next question: If a ccTLD NS gets a /32, why shouldn't a Authoratitative NS for a real big number of Domains (of a domain hoster, for example) get a /32? What is the difference between a ccTLD Nameserver and any other authoritative NS? I think the problem is not, that ccTLD Nameservers do not get a assignment, the problem is much more general: Addresses are assigned in the way that suits ISPs quite nicely but for sites is a major pain in the rear end. As long as this does not change IPv6 will stay what it is today: A nice platform for testing and playing without any business relevance. Nils -- Der Minister nimmt flüsternd den Bischof beim Arm: "Halt Du sie dumm - ich halt sie Arm" [Reinhard Mey, 'Sei Wachsam']
On 25-feb-05, at 19:12, Nils Ketelsen wrote:
And now the next question: If a ccTLD NS gets a /32, why shouldn't a Authoratitative NS for a real big number of Domains (of a domain hoster, for example) get a /32? What is the difference between a ccTLD Nameserver and any other authoritative NS?
And if a big nameserver gets a /32, why doesn't a bank? I mean, most people value getting at their money more than getting at their homepage. But if the bank gets to multihome, then why not large etailers? And if the large ones get to, what about the medium-sized ones?
I think the problem is not, that ccTLD Nameservers do not get a assignment, the problem is much more general: Addresses are assigned in the way that suits ISPs quite nicely but for sites is a major pain in the rear end.
ISPs know that keeping the routing infrastructure working is very important. End-users generally don't.
As long as this does not change IPv6 will stay what it is today: A nice platform for testing and playing without any business relevance.
And if we give everyone PI IPv6 will probably blow up even sooner than IPv4 so we can start again from scratch.
On Fri, Feb 25, 2005 at 07:25:25PM +0100, Iljitsch van Beijnum wrote:
On 25-feb-05, at 19:12, Nils Ketelsen wrote:
And now the next question: If a ccTLD NS gets a /32, why shouldn't a Authoratitative NS for a real big number of Domains (of a domain hoster, for example) get a /32? What is the difference between a ccTLD Nameserver and any other authoritative NS?
And if a big nameserver gets a /32, why doesn't a bank? I mean, most people value getting at their money more than getting at their homepage.
But if the bank gets to multihome, then why not large etailers?
And if the large ones get to, what about the medium-sized ones?
That is exactly my point, yes.
I think the problem is not, that ccTLD Nameservers do not get a assignment, the problem is much more general: Addresses are assigned in the way that suits ISPs quite nicely but for sites is a major pain in the rear end.
ISPs know that keeping the routing infrastructure working is very important. End-users generally don't.
This approach has two major flaws: 1. If a Service Provider starts to decide what is good for his customers and what they should not get, their business is usually at their end of life. As long as ISPs do whats good for them, instead of what their customers want, in the IPv6 world, IPv6 stays a provider toy. 2. You try to solve a technical problem with policies, which works as well as trying to fix politics with technical solutions. I have said it more then once and I still believe it: Routers will be able to handle Billions of routing table entries long before anyone will invest huge amounts of money to migrate his current infrastructure to a new one that provides far less features.
As long as this does not change IPv6 will stay what it is today: A nice platform for testing and playing without any business relevance. And if we give everyone PI IPv6 will probably blow up even sooner than IPv4 so we can start again from scratch.
If you don't, you will have a small routing table and no customers sending any packets you can route. Nils -- Would you like to play a game?
On 25-feb-05, at 20:37, Nils Ketelsen wrote:
As long as this does not change IPv6 will stay what it is today: A nice platform for testing and playing without any business relevance.
And if we give everyone PI IPv6 will probably blow up even sooner than IPv4 so we can start again from scratch.
If you don't, you will have a small routing table and no customers sending any packets you can route.
Fortunately we don't have to give everyone PI to make IPv6 a good place to be. Less than 20000 people have an AS in the IPv4 table currently, and somehow the rest of us manage to get by. So let's give the multi6/shim6 stuff a chance to work rather than start messing up IPv6 now. There will still be plenty of time to do that later.
Nils Ketelsen wrote:
And now the next question: If a ccTLD NS gets a /32, why shouldn't a Authoratitative NS for a real big number of Domains (of a domain hoster, for example) get a /32? What is the difference between a ccTLD Nameserver and any other authoritative NS?
just as a side note: it's not the number of domains/zones that matters here. In the case of a multi-zone server they are not forced to serve all zones from a single name or IP address, i.e. they can achieve resilience and load distribution by other means. Some problems may still be similar, though. -Peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 7:00 PM, Jeroen Massar wrote:
Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32....
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQh9rKKarNKXTPFCVEQLYiQCfUxRhS0Ueb9o7KXiY1eb6WfPHvhsAoOHg xtDIMvMtAEUId01dRZHIBCj8 =pU8e -----END PGP SIGNATURE-----
On 25-feb-05, at 19:14, Kurt Erik Lindqvist wrote:
Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32....
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely.
How is it different if this japanese /32 is in my routing tables? I'm getting pretty tired of this IP business. Maybe I should do something easy for a living, like breeding flying pigs.
On Fri, 2005-02-25 at 19:28 +0100, Iljitsch van Beijnum wrote:
On 25-feb-05, at 19:14, Kurt Erik Lindqvist wrote:
Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32....
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely.
How is it different if this japanese /32 is in my routing tables?
Just setup shop in Japan and experience it yourself ;)
I'm getting pretty tired of this IP business. Maybe I should do something easy for a living, like breeding flying pigs.
Oeh neat, as long as you attach them to a strong enough wire and don't let them drop their droplets in my backyard ;) On Fri, 2005-02-25 at 13:12 -0500, Nils Ketelsen wrote:
On Fri, Feb 25, 2005 at 07:00:27PM +0100, Jeroen Massar wrote:
Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32....
And now the next question: If a ccTLD NS gets a /32, why shouldn't a Authoratitative NS for a real big number of Domains (of a domain hoster, for example) get a /32? What is the difference between a ccTLD Nameserver and any other authoritative NS?
Let me see, in the current RIPE allocation list*, there is a school at 2001:4b20::/32 consisting of basically two buildings, there is a registrar at 2001:4b98::/32, who do not do hosting I guess. And there are a really large number of "ISP's" who really do not have more than 2 19" racks worth of equipment. I really wonder why people are complaining that they can't get a prefix. Really, if you are not able to become LIR, and get a prefix, while they quite apparently can, then you should simply quit change your job IMHO. Greets, Jeroen *, see http://www.sixxs.net/tools/grh/tla/ripe/
On Fri, Feb 25, 2005 at 07:38:43PM +0100, Jeroen Massar wrote:
Let me see, in the current RIPE allocation list*, there is a school at 2001:4b20::/32 consisting of basically two buildings, there is a registrar at 2001:4b98::/32, who do not do hosting I guess. And there are a really large number of "ISP's" who really do not have more than 2 19" racks worth of equipment.
I really wonder why people are complaining that they can't get a prefix. Really, if you are not able to become LIR, and get a prefix, while they quite apparently can, then you should simply quit change your job IMHO.
So, what you are saying is, that the current policy is good, because it can be bypassed by just lying? Call me old fashioned, but I think lying is a bad thing, that you do not do just because you have an advantage of it. I'd rather go the rough way and try to fix the policy that encourages this kind of behaviour instead of the easy way. Nils -- Newsreaders still feel it is worth a special and rather worrying mention if, for instance, a crime was planned by people over the Internet. They don't bother to mention when criminals use the telephone or the M4, or discuss their dastardly plans over a cup of tea. -- Douglas Adams --
On Fri, 2005-02-25 at 14:42 -0500, Nils Ketelsen wrote:
On Fri, Feb 25, 2005 at 07:38:43PM +0100, Jeroen Massar wrote:
Let me see, in the current RIPE allocation list*, there is a school at 2001:4b20::/32 consisting of basically two buildings, there is a registrar at 2001:4b98::/32, who do not do hosting I guess. And there are a really large number of "ISP's" who really do not have more than 2 19" racks worth of equipment.
I really wonder why people are complaining that they can't get a prefix. Really, if you are not able to become LIR, and get a prefix, while they quite apparently can, then you should simply quit change your job IMHO.
So, what you are saying is, that the current policy is good, because it can be bypassed by just lying?
If you say they are lying, then complain to RIPE NCC that they are doing their jobs wrongly. Apparently everybody who has gotten an allocation up to now have been able to reason that they need the allocation under the current policies. If you are not able to do so, though luck, you most likely don't need it in the first place then. Greets, Jeroen
Jftr,
Let me see, in the current RIPE allocation list*, there is a school at 2001:4b20::/32 consisting of basically two buildings, there is a registrar at 2001:4b98::/32, who do not do hosting I guess. And there are a really large number of "ISP's" who really do not have more than 2 19" racks worth of equipment.
I really wonder why people are complaining that they can't get a prefix. Really, if you are not able to become LIR, and get a prefix, while they quite apparently can, then you should simply quit change your job IMHO.
I've asked the school; they are no end-site, they provide ISP services for swiss schools. So, maybe you should rethink what you wrote above. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Mon, 2005-02-28 at 11:41 +0100, Elmar K. Bins wrote:
Jftr,
Let me see, in the current RIPE allocation list*, there is a school at 2001:4b20::/32 consisting of basically two buildings, there is a registrar at 2001:4b98::/32, who do not do hosting I guess. And there are a really large number of "ISP's" who really do not have more than 2 19" racks worth of equipment.
I really wonder why people are complaining that they can't get a prefix. Really, if you are not able to become LIR, and get a prefix, while they quite apparently can, then you should simply quit change your job IMHO.
I've asked the school; they are no end-site, they provide ISP services for swiss schools.
I wonder why I could then only find two buildings in that place and why SWITCH (www.switch.ch) is already doing it for the rest of the universities and schools in Switzerland ;) Greets, Jeroen
jeroen@unfix.org (Jeroen Massar) wrote:
I've asked the school; they are no end-site, they provide ISP services for swiss schools.
I wonder why I could then only find two buildings in that place and why SWITCH (www.switch.ch) is already doing it for the rest of the universities and schools in Switzerland ;)
That you and I cannot find more information might be subject to us not having an employment contract with them... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Mon, 2005-02-28 at 11:57 +0100, Elmar K. Bins wrote:
jeroen@unfix.org (Jeroen Massar) wrote:
I've asked the school; they are no end-site, they provide ISP services for swiss schools.
I wonder why I could then only find two buildings in that place and why SWITCH (www.switch.ch) is already doing it for the rest of the universities and schools in Switzerland ;)
That you and I cannot find more information might be subject to us not having an employment contract with them...
It does not matter if there is more information of not, they have qualified for the space and that is it. The point was that if others are not capable then that is really their problem, they demonstrated that it is possible, like many others. Greets, Jeroen
jeroen@unfix.org (Jeroen Massar) wrote:
That you and I cannot find more information might be subject to us not having an employment contract with them...
It does not matter if there is more information of not, they have qualified for the space and that is it. The point was that if others are not capable then that is really their problem, they demonstrated that it is possible, like many others.
No. They are no end site (like you implicitly suspected), full stop. The end site problem still persists. Polemics doesn't help. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Mon, 2005-02-28 at 14:54 +0100, Elmar K. Bins wrote:
jeroen@unfix.org (Jeroen Massar) wrote:
That you and I cannot find more information might be subject to us not having an employment contract with them...
It does not matter if there is more information of not, they have qualified for the space and that is it. The point was that if others are not capable then that is really their problem, they demonstrated that it is possible, like many others.
No. They are no end site (like you implicitly suspected), full stop. The end site problem still persists.
End sites should not get a entry in the global routing table. Full Stop ;) This is because end-sites are provided with IP by their upstreams. Full Stop. Greets, Jeroen
On Mon, Feb 28, 2005 at 03:00:33PM +0100, Jeroen Massar wrote:
End sites should not get a entry in the global routing table. Full Stop ;)
This is because end-sites are provided with IP by their upstreams. Full Stop.
==> Large scale IPv6 adoption: Full Stop. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
jeroen@unfix.org (Jeroen Massar) wrote:
End sites should not get a entry in the global routing table. Full Stop ;)
This obviously doesn't conform to current RIPE v4 policies. Discrepancy to be solved. Apart from this I can't see a way to get you out of your ivory tower... Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Mon, 2005-02-28 at 15:52 +0100, Elmar K. Bins wrote:
jeroen@unfix.org (Jeroen Massar) wrote:
End sites should not get a entry in the global routing table. Full Stop ;)
This obviously doesn't conform to current RIPE v4 policies. Discrepancy to be solved.
Apart from this I can't see a way to get you out of your ivory tower...
Which ivory tower? The one with the big banner to the other big ivory tower containing the words that IPv4 routing policies do not equal the ones for IPv6? Greets, Jeroen
jeroen@unfix.org (Jeroen Massar) wrote:
This obviously doesn't conform to current RIPE v4 policies. Discrepancy to be solved.
Apart from this I can't see a way to get you out of your ivory tower...
Which ivory tower? The one with the big banner to the other big ivory tower containing the words that IPv4 routing policies do not equal the ones for IPv6?
More the like of that which Daniel referred to. Real-Life v6 will not happen unless certain infrastructure, often provided by end sites, is online. Maybe end sites need to be classified further. But then...let's await future discussions on the matter; I don't like preaching to walls, so maybe somebody else can turn the walls into something softer :-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
Hi, On Mon, Feb 28, 2005 at 04:21:33PM +0100, Elmar K. Bins wrote:
Maybe end sites need to be classified further. But then...let's await future discussions on the matter; I don't like preaching to walls, so maybe somebody else can turn the walls into something softer :-)
So far, nobody has proposed a "globally visible v6 to <important end sites>" policy yet. People are clearly unhappy, and blaiming policies, but are not making specific proposals. One could start with the "critical infrastructure" policy from ARIN, but I keep saying that Google is much more critical to the average network user than one specific nameserver out of the NS set of a random ccTLD registry... Most large enterprises will think of themselves as much more important than anybody else. So it's not easy to come up with a set of rules "who is permitted to announce a globally visible prefix and who isn't". Nils seems to aim for "everybody is", which is something I'm afraid of... (and I don't see that "vendors will deliver routers that can handle $Billions of routes" anytime soon, seeing that vendors are still shipping "top of the line" products that can't do more than 256k IPv4 prefixes). OTOH, one might see this "IPv6 deployment isn't happening because we can't get addresses!!!" as a pretty lame excuse - /48 multihoming has serious problems, but if you really *want* to get started with IPv6, it works, for the time being. 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
gert@space.net (Gert Doering) wrote:
So far, nobody has proposed a
"globally visible v6 to <important end sites>"
policy yet. People are clearly unhappy, and blaiming policies, but are not making specific proposals.
Like said - it should have been underway already...
One could start with the "critical infrastructure" policy from ARIN, but I keep saying that Google is much more critical to the average network user than one specific nameserver out of the NS set of a random ccTLD registry...
Pah! (And yes, you're right)
still shipping "top of the line" products that can't do more than 256k IPv4 prefixes).
In the forwarding table, not in the BGP table. Or did I understand that wrongly?
OTOH, one might see this "IPv6 deployment isn't happening because we can't get addresses!!!" as a pretty lame excuse - /48 multihoming has serious problems, but if you really *want* to get started with IPv6, it works, for the time being.
... as long as your transit providers know each other, agree not to filter, and you're happy with the fallback connectivity through the block owner. We're in a lucky position, not everybody is. But: I wouldn't dream of trying PI (v4 or v6) for our home location, my concern, as you know, is different. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Mon, 2005-02-28 at 16:43 +0100, Elmar K. Bins wrote:
gert@space.net (Gert Doering) wrote:
So far, nobody has proposed a
"globally visible v6 to <important end sites>"
policy yet. People are clearly unhappy, and blaiming policies, but are not making specific proposals.
Like said - it should have been underway already...
As you so 'badly' want one, write something up and describe exactly what you want, now you are just running up to the walls.
still shipping "top of the line" products that can't do more than 256k IPv4 prefixes).
In the forwarding table, not in the BGP table. Or did I understand that wrongly?
BGP is only 'limited' in the number of updates that can be handled. The likelyhood that more entries cause more updates will rise, next to that, we only have max ~60k ASN's anyway at this moment, thus even if every ASN would announce 1 IPv6 prefix it would stop at max ~60k entries...
OTOH, one might see this "IPv6 deployment isn't happening because we can't get addresses!!!" as a pretty lame excuse - /48 multihoming has serious problems, but if you really *want* to get started with IPv6, it works, for the time being.
... as long as your transit providers know each other, agree not to filter, and you're happy with the fallback connectivity through the block owner. We're in a lucky position, not everybody is.
You can also ask the other transit upstream to announce your /48 for you. Nevertheless, for real end-sites, like my house, most websites and other 'endsites', if you want to multihome, have some patience shim6 to be done or as Gert said, make a really neat proposal. Multihoming on IP is silly in most cases anyway, because most of the time the cable-path is the same, thus one single silly fiber cut would take you out anyhow... and if you can pay for multiple differentiated uplinks you are most likely also big enough to claim you (will) have 200 endsites. And indeed, this ivory wall says: endsites should use the upcoming shim6 mechanism for multihoming. Greets, Jeroen
jeroen@unfix.org (Jeroen Massar) wrote:
Like said - it should have been underway already...
As you so 'badly' want one, write something up and describe exactly what you want, now you are just running up to the walls.
Maybe my english didn't make that clear: I have seen this proposal, and I've just been told it hadn't been submitted yet.
BGP is only 'limited' in the number of updates that can be handled. The likelyhood that more entries cause more updates will rise, next to that, we only have max ~60k ASN's anyway at this moment, thus even if every ASN would announce 1 IPv6 prefix it would stop at max ~60k entries...
The Sup720++ CAM tables are limited to 256K v4 entries, unless I've gotten that wrong and the boards also limit BGP paths (which I don't believe.
... as long as your transit providers know each other, agree not to filter, and you're happy with the fallback connectivity through the block owner. We're in a lucky position, not everybody is.
You can also ask the other transit upstream to announce your /48 for you.
Mind you, I prefer to advertise myself, and, as discussed, am in the lucky position that my transit ISPs are reasonable.
Nevertheless, for real end-sites, like my house, most websites and other 'endsites', if you want to multihome, have some patience shim6 to be done or as Gert said, make a really neat proposal.
See above. I consider this "house" an end site that unfortunately needs real multihoming nonetheless. But I can live with a /48 PA multihoming solution. It works well. I do need a solution for the anycast thing and shim6 will not do it.
Multihoming on IP is silly in most cases anyway, because most of the time the cable-path is the same, thus one single silly fiber cut would take you out anyhow...
We have taken great care that exactly this is untrue.
and if you can pay for multiple differentiated uplinks you are most likely also big enough to claim you (will) have 200 endsites.
End sites are no ISPs. Try as I might, I will not have different companies as my customers. There seem to be different kinds of end-sites, maybe we are one type and you're the other. ;-) Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Mon, Feb 28, 2005 at 05:14:56PM +0100, Elmar K. Bins wrote:
You can also ask the other transit upstream to announce your /48 for you.
Mind you, I prefer to advertise myself, and, as discussed, am in the lucky position that my transit ISPs are reasonable.
Unfortunately this mainly leads to bad connectivity as half of the IPv6 world filters /48. Results are overly long AS_PATHs and really ugly transit connections upteen times over the big ponds. Not in your case as you can peer directly at DECIX and Space.Net's quite well connected upstream Tiscali doesn't filter, but for other /48 wannabe-multihomers this looks MUCH worse. Random example: http://www.sixxs.net/tools/grh/lg/?find=2001:418::/32 PA more-specific "multihoming" is _not_ a solution. If your link to the PA-space providing ISP is down, you're unreachable from a lot of sites. And routing problem debugging becomes a major pain. Anyway, this isn't about DNS nameserver anycasting anymore, so... :-) Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 28-feb-05, at 17:49, Daniel Roesen wrote:
You can also ask the other transit upstream to announce your /48 for you.
Mind you, I prefer to advertise myself, and, as discussed, am in the lucky position that my transit ISPs are reasonable.
Unfortunately this mainly leads to bad connectivity as half of the IPv6 world filters /48.
As long as your two transit ISPs accept the /48 from eachother, you'll have redundancy so this is not fatal. And if we can write up a nice document that outlines how people can filter out "remote" /48s because having those in their routing tables has no added value, while allowing "close by" /48s that help optimize traffic flow, this could work out very well. The good part is that if the uptake of this way of multihoming isn't excessive, there is no need to filter at all and we're all happy. But if it gets out of hand, people can filter without breaking connectivity. So this takes having to correctly guess the amount of multihoming in the future out of the equation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-01, at 21.09, Iljitsch van Beijnum wrote:
And if we can write up a nice document that outlines how people can filter out "remote" /48s because having those in their routing tables has no added value, while allowing "close by" /48s that help optimize traffic flow, this could work out very well.
The good part is that if the uptake of this way of multihoming isn't excessive, there is no need to filter at all and we're all happy. But if it gets out of hand, people can filter without breaking connectivity. So this takes having to correctly guess the amount of multihoming in the future out of the equation.
It also have the potential to give us even more asymmetrical routing than what we have today. Which might or might not be a problem. YMMV. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiTXI6arNKXTPFCVEQJJmACgr+FQm5MF2SjqHqJMC66mw7hLFTwAnikA xvQltjWS1J6/B13KNKV9RAck =FCeo -----END PGP SIGNATURE-----
On Tue, Mar 01, 2005 at 09:09:18PM +0100, Iljitsch van Beijnum wrote:
Unfortunately this mainly leads to bad connectivity as half of the IPv6 world filters /48.
As long as your two transit ISPs accept the /48 from eachother, you'll have redundancy so this is not fatal.
I consider 15-hop AS_PATHs crossing ponds multiple times and tunnels all over etc with 500ms+ RTT quite fatal, compared to let's say 3-hop AS_PATH all native.
And if we can write up a nice document that outlines how people can filter out "remote" /48s because having those in their routing tables has no added value, while allowing "close by" /48s that help optimize traffic flow, this could work out very well.
No, won't. The problem operators on the net don't update filters, let alone read "nice documents" how to do things properly. And there is still:
But if it gets out of hand, people can filter without breaking connectivity.
Wrong. You cannot filter PA-more-specific-multihomer-prefixes away without risking to lose connectivity to them. If the provider aggregate has routing problems (be it interdomain or even intradomain) and your transit cloud doesn't see the more-specific prefix announced by the multihomer, you lose connectivity. Especially in the case of the aggregate falling off the sky. A site behind upstreams who filter doesn't see the aggregate anymore, and because of filtering don't see the more-specific anymore too. POOF. There goes your connectivity. You still rely on the PA provider. You don't want that. PA-more-specific-multihoming fails (as a viable solution) as soon as people (especially transits) start filtering more-specifics. And looking at the IPv6 world today, this is already the case. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 2-mrt-05, at 3:01, Daniel Roesen wrote:
I consider 15-hop AS_PATHs crossing ponds multiple times and tunnels all over etc with 500ms+ RTT quite fatal, compared to let's say 3-hop AS_PATH all native.
[...]
The problem operators on the net don't update filters, let alone read "nice documents" how to do things properly.
[...]
You cannot filter PA-more-specific-multihomer-prefixes away without risking to lose connectivity to them. If the provider aggregate has routing problems (be it interdomain or even intradomain) and your transit cloud doesn't see the more-specific prefix announced by the multihomer, you lose connectivity.
[...] It's important to separate fundamental problems that aren't fixable, or require unpleasant compromises to be fixed, from the incidental problems that can be fixed in time and with education. The ones you list all fall in the latter category, IMO. The problem with the routing table size is that when it gets out of hand, there isn't much that you can do. We all know aggregation in IPv4 could be much better than it is now but still there is nothing anyone seems to be able to do to help the situation.
On Wed, Mar 02, 2005 at 10:50:35AM +0100, Iljitsch van Beijnum wrote:
It's important to separate fundamental problems that aren't fixable, or require unpleasant compromises to be fixed, from the incidental problems that can be fixed in time and with education. The ones you list all fall in the latter category, IMO.
Doing more-specific multihoming makes ONLY sense when planning to filter them at some point in time. Unfortunately at exactly this point, this scheme fails. This cannot be fixed in time and with education, this is a very fundamental problem of this approach. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 2-mrt-05, at 11:29, Daniel Roesen wrote:
Doing more-specific multihoming makes ONLY sense when planning to filter them at some point in time. Unfortunately at exactly this point, this scheme fails. This cannot be fixed in time and with education, this is a very fundamental problem of this approach.
No, it's not. Keeping the aggregate up isn't hard to do, and all the other stuff is even easier.
On Wed, Mar 02, 2005 at 11:38:50AM +0100, Iljitsch van Beijnum wrote:
Doing more-specific multihoming makes ONLY sense when planning to filter them at some point in time. Unfortunately at exactly this point, this scheme fails. This cannot be fixed in time and with education, this is a very fundamental problem of this approach.
No, it's not. Keeping the aggregate up isn't hard to do, and all the other stuff is even easier.
"isn't hard to do". Yeah, I have seen vomitting horses, right in front of the pharmacy. With prescription in their mouth. What do you do against intradomain routing problems? Loops? DDoS congestion? With proper BGP multihoming you (as end site) can just withdraw your announcement via this problematic uplink. Doesn't help you with more-specific pseudomultihoming and people filtering the more-specific. Traffic to you still ends up in the problem area. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 2-mrt-05, at 11:45, Daniel Roesen wrote:
What do you do against intradomain routing problems? Loops? DDoS congestion?
Read my book, it's all in there.
With proper BGP multihoming you (as end site) can just withdraw your announcement via this problematic uplink. Doesn't help you with more-specific pseudomultihoming and people filtering the more-specific.
I appreciate that having your own prefix in the global table makes lots of stuff easier, but what if everyone wants this? It just doesn't scale. As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them.
----- Original Message ----- From: "Iljitsch van Beijnum" <iljitsch@muada.com>
On 2-mrt-05, at 11:45, Daniel Roesen wrote:
What do you do against intradomain routing problems? Loops? DDoS congestion?
Read my book, it's all in there.
Hi I think it would be much better if you explained it instead. Some of us (just a few though) may not have read that book.
With proper BGP multihoming you (as end site) can just withdraw your announcement via this problematic uplink. Doesn't help you with more-specific pseudomultihoming and people filtering the more-specific.
I appreciate that having your own prefix in the global table makes lots of stuff easier, but what if everyone wants this? It just doesn't scale.
You seem to be too worried about the vendor implementations rather than the BGP specification which scales greatly and way beyond todays and tomorrows size of the global routing table. It doesn't affect us as the customer before no bgp vendor in the world can deliver a working BGP implementation. I am quite confident that this will never happen. As a matter of fact, I am willing to bet all my obsolete Cisco equipment on it.
As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them.
It would be interesting if this could be implemented in BGP5 as a standard so you can announce more specific prefixes that is not to be routed instead of just announcing the ones that is supposed to be routed. Jørgen Hovland ENK
On Wed, 2005-03-02 at 11:53 +0000, Jørgen Hovland wrote:
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
As for the DoS issue, your transit ISPs can create blackhole communities so you can have them blackhole the traffic for individual /32s (if desired) when those are under attack by announcing even more specific more specifics with this community on them.
It would be interesting if this could be implemented in BGP5 as a standard so you can announce more specific prefixes that is not to be routed instead of just announcing the ones that is supposed to be routed.
SSUD (Source Specific Unicast Deny), the reverse of SSM in Multicast? The only issue with it is that if somebody has 200 prefixes and each prefix has 100 SSUD entry's you have 200.000 extra prefixes in the routing table... Though you could say that one is allowed to have a max of 5 SSUD's per prefix or some other limit and if the limit is hit the SSUD becomes an exclude for ::/0 or 0.0.0.0 aka anything... Unfortunately DDoS's come from botnets and botnets have more than 200 sources, read, more likely something like 200.000 or 500.000 sources, depending on the person who likes you so very much... Greets, Jeroen
On 2-mrt-05, at 12:53, Jørgen Hovland wrote:
What do you do against intradomain routing problems? Loops? DDoS congestion?
Read my book, it's all in there.
I think it would be much better if you explained it instead. Some of us (just a few though) may not have read that book.
I would assume that this information is available elsewhere too, it's not like I came up with it all on my own. But if there is any interest I'd be happy to do a tutorial at one of the next RIPE meetings.
On Wed, 2 March 2005 11:38:50 +0100, Iljitsch van Beijnum wrote:
On 2-mrt-05, at 11:29, Daniel Roesen wrote:
Doing more-specific multihoming makes ONLY sense when planning to filter them at some point in time. Unfortunately at exactly this point, this scheme fails. This cannot be fixed in time and with education, this is a very fundamental problem of this approach.
No, it's not. Keeping the aggregate up isn't hard to do, and all the other stuff is even easier.
"No, it's not." - don't you think you said a little too quick? Different network, different ppl, complexity++? How many routers did you say have internationally, and at what networks did you gain experience previously? Alexander -- Alexander Koch <koch@tiscali.net> / ako4-ripe Tiscali Int., Peering Coordination Phone +49 6103 916 480, Fax +49 6103 916 464
On Wed, Mar 02, 2005 at 11:38:50AM +0100, Iljitsch van Beijnum wrote:
On 2-mrt-05, at 11:29, Daniel Roesen wrote:
Doing more-specific multihoming makes ONLY sense when planning to filter them at some point in time. Unfortunately at exactly this point, this scheme fails. This cannot be fixed in time and with education, this is a very fundamental problem of this approach. No, it's not. Keeping the aggregate up isn't hard to do, and all the other stuff is even easier.
I want a second uplink to another provider for one simple reason: I do not trust one single provider to deliver the Level of service I want. Making a backup, that still relies on the first provider to work is only of limited use. I want a backup, that also works if Provider1 loses all his peers, burns down, goes bankrupt etc. Nils -- Will trade links for food. [geklaut bei www.userfriendly.org]
On 2-mrt-05, at 14:46, Nils Ketelsen wrote:
Keeping the aggregate up isn't hard to do
Making a backup, that still relies on the first provider to work is only of limited use. I want a backup, that also works if Provider1 loses all his peers, burns down, goes bankrupt etc.
Another party can set up a route server at an exchange point that injects a backup route for the aggregate, or multiple ISPs can share an aggregate. The specifics aren't all that interesting, the point is that there are more ways to skin a cat than doing everything the way we always did but now with longer addresses.
Hi, On Mon, Feb 28, 2005 at 04:39:19PM +0100, Gert Doering wrote:
So far, nobody has proposed a
"globally visible v6 to <important end sites>"
policy yet. People are clearly unhappy, and blaiming policies, but are not making specific proposals.
Just to stir discussion a bit... there's a policy proposal in the ARIN region to give a v6 network block to "every end site that qualifies for an AS number". http://www.arin.net/mailing_lists/ppml/3151.html (I'm purposely not commenting this at this time). 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 19:28, Iljitsch van Beijnum wrote:
On 25-feb-05, at 19:14, Kurt Erik Lindqvist wrote:
Also for the folks complaining about rootservers getting a /32 and those not being available to ccTLD servers, why don't you move to the APNIC region, there even the .jp root has a /32....
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely.
How is it different if this japanese /32 is in my routing tables?
I'm getting pretty tired of this IP business. Maybe I should do something easy for a living, like breeding flying pigs.
I was referring to the fact that we don't have NIRs under RIPE. That is different. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDLqKarNKXTPFCVEQJT5gCfWLZiIZD6FHjJ5nmnq7L6LppLbwMAoICe xle15MbmI+STqX6Vww91q21d =m6EI -----END PGP SIGNATURE-----
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely.
Which, as the ITU proposes, we'll face with v6 anyway. Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2005, at 20:04, Elmar K. Bins wrote:
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely.
Which, as the ITU proposes, we'll face with v6 anyway.
Well, instead of RIPE dinners we will just have to used to do coctail-parties in Geneva in suits. At least the skiing is good :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiDMf6arNKXTPFCVEQIwFgCfZAfGZlOc2dPRTZnLVPr8EeJCBH8Anj/I FVs/JQVWpkP7jbuYQ0GKAKa8 =gTiA -----END PGP SIGNATURE-----
On Sat, 2005-02-26 at 20:22 +0100, Kurt Erik Lindqvist wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 25, 2005, at 20:04, Elmar K. Bins wrote:
kurtis@kurtis.pp.se (Kurt Erik Lindqvist) wrote:
Well, in JP you also have to get your addresses from a NIR and you will have a local whoisdb in Japaneese...etc...it's a different model entirely.
On the whois front I am actually extremely happy that AFRINIC got raised by RIPE as they will get the goody neato RIPE whoisdb software that at least is consistent, parsable and best of all supports CIDR. (ARIN doesn't support CIDR, though some queries they seem to strip off the /32 etc., they should simply upgrade to the RIPE version, which APNIC also uses, and then kick LACNIC to do the same)
Which, as the ITU proposes, we'll face with v6 anyway.
Well, instead of RIPE dinners we will just have to used to do coctail-parties in Geneva in suits. At least the skiing is good :-)
/me raises hand for the skiing! Though I do hope you mean a ski-suite, I don't wear ties and with the current tendency of -15 on the slopes, a normal suit will be quite chilly :) As for the IETF, shim6 WG, yes indeed give this a chance, I am quite sure this is going to work out for most people, except for the ones who really have only one thing on their minds: an entry in the routing table to be really cool and interresting. But that part should simply be like the IPv6 allocations are supposed to be: if you are a large ISP, providing for a lot (200+ seems a nice limit) customers, you are entitled a place in the routing entry, the rest can shim6, they usually don't have their own infrastructure anyways... (no your home network does not count ;) Greets, Jeroen
On Thu, Feb 24, 2005 at 07:28:43PM +0100, Iljitsch van Beijnum wrote:
Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out:
inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net
I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.
http://www.ripe.net/ripe/docs/ipv6-rootservers.html "Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to Local Internet Registries (LIRs) valid at the time of the root server assignment." An ALLOCATION makes no sense as no assignments would be done. The root server operator IS the end user of the address space. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 24-feb-05, at 20:04, Daniel Roesen wrote:
"Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to Local Internet Registries (LIRs) valid at the time of the root server assignment."
So who authorized this? It looks a lot like the RIPE NCC doesn't have to stick to its own rules when it doesn't feel like it. And it's extremely wasteful to use 2^96 addresses when only 1 is needed.
On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote:
And it's extremely wasteful to use 2^96 addresses when only 1 is needed.
That's because of people's lazy and stupid habit of derriving policy from prefix length (exceeding the valid conclusions from the IPv6 architecture documents). I would have preferred the ARIN way of using /48s (end site size). Unfortunately still many people think (or just copied some random filter recommendation) that filtering ANY /48 is a good thing, and don't update filters. Regards, Dan'overly aggressive filtering considered harmful'iel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 24-feb-05, at 21:23, Daniel Roesen wrote:
And it's extremely wasteful to use 2^96 addresses when only 1 is needed.
That's because of people's lazy and stupid habit of derriving policy from prefix length
In IPv4 it's a reasonable thing to do because enumerating all valid prefixes just isn't feasible.
Unfortunately still many people think (or just copied some random filter recommendation) that filtering ANY /48 is a good thing, and don't update filters.
Hm, maybe the read http://www.ripe.net/ripe/docs/ipv6-policies.html and saw: 4.3. Minimum allocation RIRs will apply a minimum size for IPv6 allocations to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32.
Hi, On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote:
So who authorized this?
The normal RIPE policy process. People discussed it, and decided it's a useful idea to have a way to get well-known IPv6 addresses to root servers. The resulting document is ripe-233: --------------------- snip --------------------- IPv6 Addresses for Internet Root Servers in the RIPE Region Joao Luis Silva Damas Document ID: ripe-233 Date: 24 May 2002 Abstract This document describes the special case assignment policy for Internet DNS root servers in the RIPE region. --------------------- snip --------------------- The progress that led to this policy is documented in the archives.
It looks a lot like the RIPE NCC doesn't have to stick to its own rules when it doesn't feel like it.
Please try to get your facts straigth *before* making such statements. 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 Thursday 24 February 2005 21:20, Gert Doering wrote:
Hi,
On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote:
So who authorized this?
The normal RIPE policy process. People discussed it, and decided it's a useful idea to have a way to get well-known IPv6 addresses to root servers.
Gert, I don't want to open an old discussion, but there's a difference between 'well known' addresses and a full /32. Jon
On Thursday 24 February 2005 19:04, Daniel Roesen wrote:
On Thu, Feb 24, 2005 at 07:28:43PM +0100, Iljitsch van Beijnum wrote:
Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out:
inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net
I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.
http://www.ripe.net/ripe/docs/ipv6-rootservers.html
"Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to Local Internet Registries (LIRs) valid at the time of the root server assignment."
An ALLOCATION makes no sense as no assignments would be done. The root server operator IS the end user of the address space.
Yep, that makes sense. A root server operator would be an end user - can't imagine why they'd need more than a /48 though. It would make sense to me if root servers were assigned directly from RIPE (possibly from a special allocation set as side for the root servers' use). It seems completely pointless to allocate/assign a /32 to a root server. If the root server operator gets an assignment (directly from RIPE) why does it need to be the same size as a normal minimum allocation. Regardless of min allocation size - which ISP isn't going to allow an known root server IP through. If people want to filter then let them, if they don't know what they're doing then that's their look out. Root servers should be allocated/assigned (whatever) from a known block - that way everyone knows not to filter that block. Jon
Hi, On Thu, Feb 24, 2005 at 09:27:01PM +0000, Jon Lawrence wrote:
An ALLOCATION makes no sense as no assignments would be done. The root server operator IS the end user of the address space.
Yep, that makes sense. A root server operator would be an end user - can't imagine why they'd need more than a /48 though.
They need a /128. But experience has shown that BGP participants *do* filter, and as such, it was decided to go for a /32 in RIPE land. ARIN does /48s.
It would make sense to me if root servers were assigned directly from RIPE (possibly from a special allocation set as side for the root servers' use).
This is the way it is done.
It seems completely pointless to allocate/assign a /32 to a root server. If the root server operator gets an assignment (directly from RIPE) why does it need to be the same size as a normal minimum allocation.
BGP filters. But hey, so what. There are roughly 4 billion /32s - what do you gain by saving 10 /32s? The number of routing table entries (which are a larger problem than "exhaustion of the available /32s") doesn't change.
Regardless of min allocation size - which ISP isn't going to allow an known root server IP through. If people want to filter then let them, if they don't know what they're doing then that's their look out.
Root servers should be allocated/assigned (whatever) from a known block - that way everyone knows not to filter that block.
At the time the policy was written, people thought that this way would be better. On the subject of root servers, people tend to be conservative. OTOH, no policy that can't be changed if people think otherwise today. 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
sorry for replying to this to all of the mailinglist. On Thu, 24 Feb 2005, Iljitsch van Beijnum wrote: <znip:
inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net
I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.
This is pointless discussion, only point of it would maybe be to making it clear that the VERY few DNS _root-servers_ there are out there, are the ONLY thing important enough to get it's own /32. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
participants (14)
-
Alexander Koch -
Daniel Roesen -
Elmar K. Bins -
Gert Doering -
Iljitsch van Beijnum -
Jeroen Massar -
Jon Lawrence -
Jørgen Hovland -
Kurt Erik Lindqvist -
Nils Ketelsen -
Nils Ketelsen -
Peter Koch -
Randy Bush -
Roger Jorgensen