IPv6 assignments to DNS root servers in the RIPE region
Dear all, below find a proposal for a policy enabling the assignment of blocks of IPv6 addresses to Internet DNS root servers in the RIPE region. I would like to use the opportunity to request from the chairman of the LIR WG to include this point for discussion in the WG meeting next week. Of course, discussion in the mailing list is welcome. Best regards, Joao Damas RIPE NCC **************** This proposal requests the adoption of a special IPv6 assignment policy for Internet DNS root servers. It does not apply to any other infrastructure. Specifically, this is not a request for a generic "special infrastructure" IPv6 assignment policy. --- IPv6 address assignments to Internet DNS root servers in the RIPE region Internet DNS root servers are particularly critical elements of the Internet's infrastructure. They need to be operated in a neutral and professional manner which will not impose any artificial or unnecessary barriers for access to their designated services. DNS resolvers and resolving name servers need to be pre-configured with the network addresses of the root name servers. This makes these addresses special and not easy to change. Hence this special policy. 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 LIRs valid at the time of the root server assignment. The assigned prefix is only for root server operations and support functions related directly to the operations, such as monitoring, statistics, etc., and is bound to the root server service itself. It is not associated with the organization/s that operate the root server at a particular point in time and these organizations should not use the address space to provide any services not related to the root server. Should the operational responsibility for a DNS root server move to a new organization, the IPv6 address space associated with the server will also move to the new organization. The old and the new organizations must update the registration information with the RIPE NCC. If the new location of the root name server is outside the RIPE region, the address space must be returned to the RIPE NCC and a new assignment must be requested from the appropriate RIR. If a root server stops operating within the RIPE region, the address space will be returned to the RIPE NCC and marked as "reserved" for a suitably long period of time. *******************
DNS resolvers and resolving name servers need to be pre-configured with the network addresses of the root name servers. This makes these addresses special and not easy to change. Hence this special policy.
while the addresses are well-known and embedded in all sorts of places, what difference does the actual integer value of those addresses make?
Should the operational responsibility for a DNS root server move to a new organization, the IPv6 address space associated with the server will also move to the new organization.
so, you want give provider independence to the root servers. i.e, this is based on the idea that root servers, one of which which moves about every five or more years, and the protocols takes care of following the hints file anyway, are more deserving of provider independence than other members' servers and services. but i am sure that cnn.com they are just as deserving and needy. i sure think that my site is. i don't buy it. randy
At 18:47 22/04/2002, Randy Bush wrote:
so, you want give provider independence to the root servers. i.e, this is based on the idea that root servers, one of which which moves about every five or more years, and the protocols takes care of following the hints file anyway, are more deserving of provider independence than other members' servers and services.
Look at it the other way around: You do not want a provider to keep that space if they should not. Daniel
so, you want give provider independence to the root servers. i.e, this is based on the idea that root servers, one of which which moves about every five or more years, and the protocols takes care of following the hints file anyway, are more deserving of provider independence than other members' servers and services. Look at it the other way around: You do not want a provider to keep that space if they should not.
as currently, in v4, 'that space' was the providers in the first place, of course i do. randy
At 7:40 -0400 23/4/02, Randy Bush wrote:
so, you want give provider independence to the root servers. i.e, this is based on the idea that root servers, one of which which moves about every five or more years, and the protocols takes care of following the hints file anyway, are more deserving of provider independence than other members' servers and services. Look at it the other way around: You do not want a provider to keep that space if they should not.
as currently, in v4, 'that space' was the providers in the first place, of course i do.
you mean keep it if they should not? Anyway, if anything, time should make us smarter. I understand your argument about "I am special, you are special, we are all special". The difference between these machines and others is that these ones are needed by everyone. When you say the protocol "WILL" take care of the hints file, maybe you wanted to say: the protocol "SHOULD" take care... The request to get the addresses back is, as Daniel pointed out, a reasonable one from an operations point of view. If a root server were to move and a change of address was required, it might be a good idea not to have another name server at the same address, or if you have one, let it be something that would be helping towards a smooth transition. Joao
Anyway, if anything, time should make us smarter.
some days i wonder. this is one example that makes me wonder.
The difference between these machines and others is that these ones are needed by everyone. When you say the protocol "WILL" take care of the hints file, maybe you wanted to say: the protocol "SHOULD" take care...
"DOES" would probably be most appropriate, as it works in theory and has been shown to work in practice
The request to get the addresses back is, as Daniel pointed out, a reasonable one from an operations point of view.
of course
If a root server were to move and a change of address was required, it might be a good idea not to have another name server at the same address, or if you have one, let it be something that would be helping towards a smooth transition.
yup. it's called prudent operation. it's not like we have not been here before and don't have the coffee mug. people should also not announce bogus routes to the root servers. so, should we hard-wire the routes into the routers? randy
At 8:08 -0400 23/4/02, Randy Bush wrote:
"DOES" would probably be most appropriate, as it works in theory and has been shown to work in practice
For BIND versions that support IPv6 that is true. I am not sure about other DNS server software and every day there are more, which is a good thing(tm).
If a root server were to move and a change of address was required, it might be a good idea not to have another name server at the same address, or if you have one, let it be something that would be helping towards a smooth transition.
yup. it's called prudent operation. it's not like we have not been here before and don't have the coffee mug. people should also not announce bogus routes to the root servers. so, should we hard-wire the routes into the routers?
Sure, if it is your router you can do whatever you want with it. I am told that just behind the upcoming RIPE meeting's venue there are some fine artists specialised in etching with different colours of ink and some electrical needles. Seriously now. I strongly believe that if a root server were to stop operations, it would be in everyone's benefit that either the address space where it is hosted moves with it OR **the address space which it was using is returned** I do not want to find out that my name server is using an old address, which replies with a hints file that might not be the one I expect. For the return/blockage/tagging to be operationally feasible, no unrelated services can ride on that address space. Joao
Seriously now. I strongly believe that if a root server were to stop operations, it would be in everyone's benefit that either the address space where it is hosted moves with it OR **the address space which it was using is returned**
nope. should nasa return 128.8 just because the server is moved from 128.8.10.90? i don't think so. but, if it is moved, they should not put anything else at 128.8.10.90 for a decade or two. randy
At 8:44 -0400 24/4/02, Randy Bush wrote:
Seriously now. I strongly believe that if a root server were to stop operations, it would be in everyone's benefit that either the address space where it is hosted moves with it OR **the address space which it was using is returned**
nope. should nasa return 128.8 just because the server is moved from 128.8.10.90? i don't think so. but, if it is moved, they should not put anything else at 128.8.10.90 for a decade or two.
No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right? Has conservation suddenly become an issue, maybe I missed that part. Joao
No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right?
oh, i forgot ipv6's rapid renumbering. i also forgot santa claus and the tooth fairy. randy
hi, On Wed, Apr 24, 2002 at 08:50:05AM -0400, Randy Bush wrote:
No, NASA should probably not return their IPv4 space. With IPv6 you can do it right, so why not do it right?
oh, i forgot ipv6's rapid renumbering. i also forgot santa claus and the tooth fairy.
Huh? What does this have to do with anything? This proposal is about NOT changing IPv6 root name server addresses, and NOT about "easy renumbering". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, On Wed, Apr 24, 2002 at 08:44:44AM -0400, Randy Bush wrote:
Seriously now. I strongly believe that if a root server were to stop operations, it would be in everyone's benefit that either the address space where it is hosted moves with it OR **the address space which it was using is returned**
nope. should nasa return 128.8 just because the server is moved from 128.8.10.90? i don't think so. but, if it is moved, they should not put anything else at 128.8.10.90 for a decade or two.
Which makes you agree with Joao, doesn't it? The way it was done with 128.8 obviously created problems, which would mean that "special networks for root name servers" might be a good thing after all... Lacking experience with root name server operations, I didn't comment the whole proposal yet, and I'm still not sure what is "the right thing to do". Let's turn it around - which of both approaches would be "the wrong thing to do", and why? Having special-case networks for every other purpose is clearly a bad thing, but I think most would agree that root name server *are* special because that's the only thing you cannot (completely) put into DNS... With the number of root name servers, I don't see any major issues due to address wastage or enormous numbers of additional routes. Just my $0.2... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
nope. should nasa return 128.8 just because the server is moved from 128.8.10.90? i don't think so. but, if it is moved, they should not put anything else at 128.8.10.90 for a decade or two. Which makes you agree with Joao, doesn't it? The way it was done with 128.8 obviously created problems, which would mean that "special networks for root name servers" might be a good thing after all...
no, quite the opposite o nasa should just not put another host at that HOST address o and the kremlin should not announce 128.8/16 o and all the other obvious things that we operators are paid to do and not do. randy
Hi Joao, and other engineers, When deploying a set of root DNS servers, I think it is a good idea to allocate some chunk of space (say a /32 or /31) and assign each nameserver that we use in the RIPE region one aggregatable /35. The other RIRs can do the same thing resulting in 24 to 48 TLAs which we can then stick onto root nameservers. If one company/AS hosts the nameserver, it starts announcing that space to the world. If it then stops running the nameserver, the whole TLA can be handed over to the next company/AS who is up to the task. Doing this will not at all mean 'renumbering' as somebody mentioned, if we can decide on a standard numberplan for these special TLAs. We are not wasting space all of a suddon, if we do this. Huitema and Durand have estimated that we have lots and lots of space if we deploy sites with /48 and TLAs with /35. However, recently at the AMS-IX noc, I talked to some engineers who explained to me that they themselves have a /48 to announce with AS1200. This of course will not be reachable anywhere else than AS1200's direct peers. This is why I would like to start a discussion on some 'special TLA' in which we allow up to /48 to pass unfiltered. This way, we can organise our nameservers within one /32, and our IX:en (2001:7f8::/32) in another and let those be in the DFZ with prefixlen <= 48. I don't really understand (yet) the fuss on Joao's proposal. groet, Pim On Mon, Apr 22, 2002 at 02:41:54PM +0200, Joao Luis Silva Damas wrote: | Dear all, | | below find a proposal for a policy enabling the assignment of blocks of IPv6 addresses to Internet DNS root servers in the RIPE region. | | I would like to use the opportunity to request from the chairman of the LIR WG to include this point for discussion in the WG meeting next week. Of course, discussion in the mailing list is welcome. | | Best regards, | Joao Damas | RIPE NCC | | | **************** | | This proposal requests the adoption of a special IPv6 assignment policy | for Internet DNS root servers. It does not apply to any other | infrastructure. | | Specifically, this is not a request for a generic "special | infrastructure" IPv6 assignment policy. | | --- | | IPv6 address assignments to Internet DNS root servers in the RIPE | region | | | Internet DNS root servers are particularly critical elements of the | Internet's infrastructure. They need to be operated in a neutral and | professional manner which will not impose any artificial or unnecessary | barriers for access to their designated services. | | DNS resolvers and resolving name servers need to be pre-configured with | the network addresses of the root name servers. This makes these | addresses special and not easy to change. Hence this special policy. | | 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 LIRs valid at the time of the root server | assignment. | | The assigned prefix is only for root server operations and support | functions related directly to the operations, such as monitoring, | statistics, etc., and is bound to the root server service itself. | | It is not associated with the organization/s that operate the root | server at a particular point in time and these organizations should not | use the address space to provide any services not related to the root | server. | | Should the operational responsibility for a DNS root server move to a | new organization, the IPv6 address space associated with the server | will also move to the new organization. The old and the new | organizations must update the registration information with the RIPE | NCC. If the new location of the root name server is outside the RIPE | region, the address space must be returned to the RIPE NCC and a new | assignment must be requested from the appropriate RIR. | | If a root server stops operating within the RIPE region, the address | space will be returned to the RIPE NCC and marked as "reserved" for a | suitably long period of time. | | ******************* -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
At 15:02 +0200 24/4/02, Pim van Pelt wrote:
Hi Joao, and other engineers,
When deploying a set of root DNS servers, I think it is a good idea to allocate some chunk of space (say a /32 or /31) and assign each nameserver that we use in the RIPE region one aggregatable /35. The other RIRs can do the same thing resulting in 24 to 48 TLAs which we can then stick onto root nameservers.
I am not sure I understand this paragraph. Are you suggesting that the address blocks where the different root servers reside should be aggregatable into one superblock? I hope not. Joao
I agree with Joao in regards to there not being one superblock. Ray
-----Original Message----- From: owner-ipv6-wg@ripe.net [mailto:owner-ipv6-wg@ripe.net] On Behalf Of Joao Luis Silva Damas Sent: Wednesday, April 24, 2002 9:11 AM To: Pim van Pelt Cc: lir-wg@ripe.net; ipv6-wg@ripe.net Subject: Re: IPv6 assignments to DNS root servers in the RIPE region
At 15:02 +0200 24/4/02, Pim van Pelt wrote:
Hi Joao, and other engineers,
When deploying a set of root DNS servers, I think it is a good idea to allocate some chunk of space (say a /32 or /31) and assign each nameserver that we use in the RIPE region one aggregatable /35. The other RIRs can do the same thing resulting in 24 to 48 TLAs which we can then stick onto root nameservers.
I am not sure I understand this paragraph. Are you suggesting that the address blocks where the different root servers reside should be aggregatable into one superblock? I hope not.
Joao
On Wed, Apr 24, 2002 at 03:10:51PM +0200, Joao Luis Silva Damas wrote: | At 15:02 +0200 24/4/02, Pim van Pelt wrote: | >Hi Joao, and other engineers, | > | >When deploying a set of root DNS servers, I think it is a good idea to | >allocate some chunk of space (say a /32 or /31) and assign each nameserver | >that we use in the RIPE region one aggregatable /35. The other RIRs can | >do the same thing resulting in 24 to 48 TLAs which we can then stick | >onto root nameservers. | | I am not sure I understand this paragraph. Are you suggesting that | the address blocks where the different root servers reside should be | aggregatable into one superblock? I hope not. I did not say that these should be combined into one aggregatable block at all. I said that if we were to allocate a /32 for use of DNS root nameservers, that we would have 8 /35s herein, and 16 /35s if we were to allocate a /31 for the use of DNS. All three RIRs would then have 24 or 48 of these /35 TLAs respectively. By the way, some paragraphs down the line I actually DID propose to create an administrative hierarchy based on /48 aggregates but I fully realise that his is going out on a limb. I think however, that if we were to use 'n' TLAs for nameservers, that I would prefer to see 'n' /48s in my routing table than 'n' /35s, this of course from the conservation point of view. The same holds for Internet Exchanges. Perhaps for other sites as well. How do we plan to have AMS-IX reachable from networks that do not peer with AS1200, if the AMS-IX is assigned only a /48 ? I see two possibilities (obvious ones, that is). 1. Allocate /35 to AMS-IX and let it announce that from AS1200 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower allowable. This latter solution could be extended to any number of services and sites. Sorry if I am rocking the boat here ;-) groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
> create an administrative hierarchy based on /48 aggregates but I fully > realise that his is going out on a limb. I think however, that if we > were to use 'n' TLAs for nameservers, that I would prefer to see 'n' > /48s in my routing table than 'n' /35s, this of course from the > conservation point of view. > > The same holds for Internet Exchanges. Perhaps for other sites as well. > How do we plan to have AMS-IX reachable from networks that do not peer > with AS1200, if the AMS-IX is assigned only a /48 ? I see two > possibilities (obvious ones, that is). > 1. Allocate /35 to AMS-IX and let it announce that from AS1200 > 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower > allowable. 3. http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html Or is this document deprecated ? IX can have non globally routable adress space. The NOC of an IX can have a /48 from any ISP, like any other organization. I don't see the problem here. -- Xavier Henner Responsable de l'exp�rimentation IPv6 Nerim -- Fournisseur d'acc�s � Internet URL: <http://www.nerim.net/>
On Wed, 2002-04-24 at 16:00, Xavier Henner wrote: > > create an administrative hierarchy based on /48 aggregates but I fully > > realise that his is going out on a limb. I think however, that if we > > were to use 'n' TLAs for nameservers, that I would prefer to see 'n' > > /48s in my routing table than 'n' /35s, this of course from the > > conservation point of view. > > > > The same holds for Internet Exchanges. Perhaps for other sites as well. > > How do we plan to have AMS-IX reachable from networks that do not peer > > with AS1200, if the AMS-IX is assigned only a /48 ? I see two > > possibilities (obvious ones, that is). > > 1. Allocate /35 to AMS-IX and let it announce that from AS1200 > > 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower > > allowable. > 3. http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html > > Or is this document deprecated ? > > IX can have non globally routable adress space. > The NOC of an IX can have a /48 from any ISP, like any other organization. > I don't see the problem here. Like for any other organization the problem here is multihoming but an additional problem is that as a neutral meeting point for a lot of ISPs/Carriers, as an Exchange we don't want a special relation with one of our members/customers and choosing one of them as a provider for address space and upstream provide does just that -- - Henk Henk Steenman tel: +31 20 514 1711 Amsterdam Internet Exchange mobile: +31 65 131 2774 http://www.ams-ix.net e-mail: Henk.Steenman@ams-ix.net
On 24-04-2002 16:00PM, "Xavier Henner" <henner@nerim.net> wrote: >> create an administrative hierarchy based on /48 aggregates but I fully >> realise that his is going out on a limb. I think however, that if we >> were to use 'n' TLAs for nameservers, that I would prefer to see 'n' >> /48s in my routing table than 'n' /35s, this of course from the >> conservation point of view. >> >> The same holds for Internet Exchanges. Perhaps for other sites as well. >> How do we plan to have AMS-IX reachable from networks that do not peer >> with AS1200, if the AMS-IX is assigned only a /48 ? I see two >> possibilities (obvious ones, that is). >> 1. Allocate /35 to AMS-IX and let it announce that from AS1200 >> 2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower >> allowable. > 3. http://www.ripe.net/ripencc/mem-services/registration/ipv6/eix-interim.html > > Or is this document deprecated ? > The problem is point 5. > IX can have non globally routable adress space. > The NOC of an IX can have a /48 from any ISP, like any other organization. As neutral IX we can not do this. This might not be as obvious since there are non-neutral IXes which are owned by one particular company. AMS-IX is not owned by one party. We are an association of all parties connecting to it. It is not desirable to have a customer relationship with one particular member. Because every member is equal. This is the basis of our existents. Although it might be not as obvious as root DNS servers it is at a smaller scale exactly the same issue. Some things can not be "owned". > I don't see the problem here. Hope this explained the problem. If not please say so and I'll try to find better words. Kind regards, Arien -- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn@ams-ix.net
Hi, On Wed, Apr 24, 2002 at 04:45:30PM +0200, Arien Vijn wrote:
IX can have non globally routable adress space. The NOC of an IX can have a /48 from any ISP, like any other organization.
As neutral IX we can not do this. This might not be as obvious since there are non-neutral IXes which are owned by one particular company.
Could we please keep these discussions separate? This is a different issue (and has been discussed to death in various IPv6-WG meetings). An IX is no different concerning *upstream* connectivity than any other "I want to be multihomed" customer. The special part about IXes is if they have a non-globally visible exchange LAN - those special networks are for *that* (only). No IX is forced to use that. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On 24-04-2002 16:49PM, "Gert Doering" <gert@space.net> wrote:
Hi,
On Wed, Apr 24, 2002 at 04:45:30PM +0200, Arien Vijn wrote:
IX can have non globally routable adress space. The NOC of an IX can have a /48 from any ISP, like any other organization.
As neutral IX we can not do this. This might not be as obvious since there are non-neutral IXes which are owned by one particular company.
Could we please keep these discussions separate? This is a different issue.
In a sense it is not. It's about situations on which the aggregation model is not applicable because of neutrality and independence. Please do not come with statements that this does not mean anything.
(and has been discussed to death in various IPv6-WG meetings).
Afraid it will be a point of discussion until this issue is resolved properly. Sorry.
An IX is no different concerning *upstream* connectivity than any other "I want to be multihomed" customer.
Who's customer? Please do understand that some IXes just can not be a customer of one individual member.
The special part about IXes is if they have a non-globally visible exchange LAN - those special networks are for *that* (only). No IX is forced to use that.
OK. We want to have the ISP exchange LAN globally visible. What are the options? Should apply for a /35 to use one /64 out of it? What good does this do to routing table sizes? Should we leave the address space assigned to *one* of the members? *Then* neutrality will mean have no meaning.
Gert Doering -- NetMaster
-- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn@ams-ix.net
Hi, On Wed, Apr 24, 2002 at 05:38:23PM +0200, Arien Vijn wrote:
On 24-04-2002 16:49PM, "Gert Doering" <gert@space.net> wrote:
IX can have non globally routable adress space. The NOC of an IX can have a /48 from any ISP, like any other organization.
As neutral IX we can not do this. This might not be as obvious since there are non-neutral IXes which are owned by one particular company.
Could we please keep these discussions separate? This is a different issue.
In a sense it is not. It's about situations on which the aggregation model is not applicable because of neutrality and independence. Please do not come with statements that this does not mean anything.
This is very much different. One is about "addresses that are special because they need to be hard-wired into applications and must not be tied to specific organizations", while the other is "organizations that want or do not want to be multihomed"
(and has been discussed to death in various IPv6-WG meetings).
Afraid it will be a point of discussion until this issue is resolved properly. Sorry.
The fact that you don't like the outcome of the previous discussions doesn't mean that it has to be intermixed into every other IPv6 policy discussion that is going on.
An IX is no different concerning *upstream* connectivity than any other "I want to be multihomed" customer.
Who's customer? Please do understand that some IXes just can not be a customer of one individual member.
Adressing and business relations are different issues.
The special part about IXes is if they have a non-globally visible exchange LAN - those special networks are for *that* (only). No IX is forced to use that.
OK. We want to have the ISP exchange LAN globally visible. What are the options?
Should apply for a /35 to use one /64 out of it? What good does this do to routing table sizes?
Where is the difference in the impact on the global routing table whether you announce one (1) /64 or one (1) /35? None. Bad argument.
Should we leave the address space assigned to *one* of the members? *Then* neutrality will mean have no meaning.
Neutrality and member-independence is important for the peering mesh (as the fabric that BGP is run over, which would make a real mess if the member providing the address space goes away). For global routing, you will be dependent on a subset of your members anyway - as not everybody might be willing to provide transit, and not everybody has comparable international connections. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Afraid it will be a point of discussion until this issue is resolved properly. Sorry.
An IX is no different concerning *upstream* connectivity than any other "I want to be multihomed" customer.
Who's customer? Please do understand that some IXes just can not be a customer of one individual member.
Why not be a "customer" af ALL individual members ? If ISP X want to be on AMS-IX, you give an IP from the /64. And the ISP gives you a /48 and transit. There is still the multihoming problem, with a little change : AMS-IX will have a lot of upstreams. You have independance and neutrality for your transit. The /64 is given directly by the RIR : you have independance and neutrality for your IP adresses The /64 has not to be routable globally. For the DNS root servers, the problem is that they must have a real PI adress which is routable globally and which will never change. -- Xavier Henner Responsable de l'exp�rimentation IPv6 Nerim -- Fournisseur d'acc�s � Internet URL: <http://www.nerim.net/>
Thanks for your suggestion Xavier. This scenario of site multi-homing might take care of global routable IPv6 services. But it is no solution for a global reachable peering LAN. With regards of services I would be reluctant to work this way. Only 12 of 130 members do "something" with IPv6. My guess is that only one might be willing to assign a /48 out of their RIR TLA. Would not be a bases to deploy IPv6 services? I don't think so. I would rather stick with our 6Bone /24 then. With regards of a global routable peering LAN. I know there are pros and cons to that. But those are for an IX and its members to decide on. Thanks again for this constructive contribution. Kind regards, Arien On 24-04-2002 21:06PM, "Xavier Henner" <henner@nerim.net> wrote:
Afraid it will be a point of discussion until this issue is resolved properly. Sorry.
An IX is no different concerning *upstream* connectivity than any other "I want to be multihomed" customer.
Who's customer? Please do understand that some IXes just can not be a customer of one individual member.
Why not be a "customer" af ALL individual members ?
If ISP X want to be on AMS-IX, you give an IP from the /64. And the ISP gives you a /48 and transit.
There is still the multihoming problem, with a little change : AMS-IX will have a lot of upstreams.
You have independance and neutrality for your transit.
The /64 is given directly by the RIR : you have independance and neutrality for your IP adresses
The /64 has not to be routable globally.
Not nescesaraly but for analisye an trouble shooiting purposes we think this this is desirbale to have this glopbaly routable.
For the DNS root servers, the problem is that they must have a real PI adress which is routable globally and which will never change.
I recognize this.
-- Xavier Henner Responsable de l'expérimentation IPv6 Nerim -- Fournisseur d'accès à Internet URL: <http://www.nerim.net/>
-- Arien Vijn tel: +31 205 141 718 Amsterdam Internet Exchange mobile: +31 651 836 444 http://www.ams-ix.net e-mail: arien.vijn@ams-ix.net
On Wed, Apr 24, 2002 at 03:38:31PM +0200, Pim van Pelt wrote:
On Wed, Apr 24, 2002 at 03:10:51PM +0200, Joao Luis Silva Damas wrote: | At 15:02 +0200 24/4/02, Pim van Pelt wrote: | >Hi Joao, and other engineers, | > | >When deploying a set of root DNS servers, I think it is a good idea to | >allocate some chunk of space (say a /32 or /31) and assign each nameserver | >that we use in the RIPE region one aggregatable /35. The other RIRs can | >do the same thing resulting in 24 to 48 TLAs which we can then stick | >onto root nameservers. | | I am not sure I understand this paragraph. Are you suggesting that | the address blocks where the different root servers reside should be | aggregatable into one superblock? I hope not.
I did not say that these should be combined into one aggregatable block at all. I said that if we were to allocate a /32 for use of DNS root nameservers, that we would have 8 /35s herein, and 16 /35s if we were to allocate a /31 for the use of DNS. All three RIRs would then have 24 or 48 of these /35 TLAs respectively.
I would prefer if IANA, rather than RIRs, assigns TLAs for root nameservers. That will make transfering root nameserver between regions easier. Root nameservers are something related to whole Internet, thus we shall not divide it between regions.
By the way, some paragraphs down the line I actually DID propose to create an administrative hierarchy based on /48 aggregates but I fully realise that his is going out on a limb. I think however, that if we were to use 'n' TLAs for nameservers, that I would prefer to see 'n' /48s in my routing table than 'n' /35s, this of course from the conservation point of view.
That would require additional filter rules. I think that allowed size of announced prefixes should be some range and we shall not partition IPv6 address space in many parts with different allowed prefix lengths. More filter rules == higher CPU usage.
The same holds for Internet Exchanges. Perhaps for other sites as well. How do we plan to have AMS-IX reachable from networks that do not peer with AS1200, if the AMS-IX is assigned only a /48 ? I see two possibilities (obvious ones, that is). 1. Allocate /35 to AMS-IX and let it announce that from AS1200 I agree with this one.
2. Make global policy to have 2001:7f8::/32 prefixlen 48 and lower allowable. See above.
Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' http://www.xs26.net jan.oravec@xs26.net
| I am not sure I understand this paragraph. Are you suggesting that | the address blocks where the different root servers reside should be | aggregatable into one superblock? I hope not. Aggregation may not make sense, but the ease of not filtering theese routes would. -hph
A quick message to clarify my initial mail as some people where getting the wrong impression. The proposal is for a policy for *IPv6* only. Also, it is not a "special infrastructure policy", it is *ONLY* for Internet DNS root servers. Regards, Joao Damas RIPE NCC
The proposal is for a policy for *IPv6* only. Also, it is not a "special infrastructure policy", it is *ONLY* for Internet DNS root servers.
and we will all sign in blood that o there will be no other magic v6 assignments and o there will be no magic v4 assignments? maybe i can live with that randy
At 14:35 +0200 29/4/02, Randy Bush wrote:
The proposal is for a policy for *IPv6* only. Also, it is not a "special infrastructure policy", it is *ONLY* for Internet DNS root servers.
and we will all sign in blood that o there will be no other magic v6 assignments and o there will be no magic v4 assignments?
maybe i can live with that
Me too Joao
randy
participants (11)
-
Arien Vijn -
Daniel Karrenberg -
Gert Doering -
Hans Petter Holen -
Henk Steenman -
Jan Oravec -
Joao Luis Silva Damas -
Pim van Pelt -
Randy Bush -
Ray Plzak -
Xavier Henner