Hi, There are some problems/errors/omissions in RIPE-210 which are causing me, and some of the ISPs trying to implement the recommendations, some problems. It seems that the choice has been made to include X.root-servers.net *and* X.gtld-servers.net, but I can find no reference to these in the description of the example configuration in S2.3. It would be good to do this so that people know what they are dampening. Also, an expansion of S1.6 would achieve this quite well. It is also worth noting that the "root networks" change from time to time, and that all ISPs should check that these network announcements are still current before implementing the recommendations. You'll be surprised how many people simply cut and paste the configuration without checking the detail. Some problems: - S1.6 refers to "probably" removing the A, D and H servers as they are on /16 prefix announcements. But A is on a /24 announcement. (Is there evidence to suggest that a /16 flaps less than a /24 - the analysis I've done in AsiaPac doesn't prove anything conclusively.) - In S2.3, B, C, D, H, K, L and M are omitted. With no explanation as to why. They are not all on /16 prefix announcements. - In S2.3, A&J network is listed twice - why? - In S2.3, if including the gtld servers is the goal, G.gtld and I.gtld are omitted. I.gtld is announced on a /24 network. The list I have been recommending to ISPs in AsiaPac for about the last year is below: ip prefix-list rootns permit 198.41.0.0/24 ! A & J ip prefix-list rootns permit 128.9.0.0/16 ! B ip prefix-list rootns permit 192.33.4.0/24 ! C ip prefix-list rootns permit 128.8.0.0/16 ! D ip prefix-list rootns permit 192.203.230.0/24 ! E ip prefix-list rootns permit 192.5.4.0/23 ! F ip prefix-list rootns permit 192.112.36.0/24 ! G ip prefix-list rootns permit 128.63.0.0/16 ! H ip prefix-list rootns permit 192.36.148.0/24 ! I ip prefix-list rootns permit 193.0.14.0/24 ! K ip prefix-list rootns permit 198.32.64.0/24 ! L ip prefix-list rootns permit 202.12.27.0/24 ! M which is basically the current list of roots and their corresponding prefixes as announced to the Internet. If the decision is to include X.gtld-servers.net, the list could be augmented as: ip prefix-list gltdns permit 198.41.3.0/24 ! A ip prefix-list gtldns permit 205.188.128.0/17 ! C ip prefix-list gtldns permit 198.17.208.0/24 ! F ip prefix-list gtldns permit 192.215.0.0/16 ! G ip prefix-list gtldns permit 216.33.64.0/19 ! H ip prefix-list gtldns permit 192.36.144.0/24 ! I ip prefix-list gtldns permit 198.41.0.0/24 ! J ip prefix-list gtldns permit 195.8.96.0/19 ! K ip prefix-list gtldns permit 210.176.0.0/16 ! M but I'd probably list them under a separate route-map section of Golden Networks. I hope the above can be incorporated in RIPE-210 so that accuracy is achieved. best wishes! philip -- -------------------------------------------------------- Philip Smith ph: +61 7 3238 8200 Consulting Engineering, Office of the CTO, Cisco Systems --------------------------------------------------------
Any moving targets, such as prefixes for root NS connectivity, should be taken out of the document. A long time ago I have proposed to set up a registry for such prefixes roughly like this: specpref: 193.0.14.0/24 type: DNS ROOT descr: K Root Server admin-c: DK58 specpref: 128.250.0.0/16 type: DNS TLD descr: AU TLD Server admin-c: RE18 specpref: 193.0.0.0/22 type: WHOIS ADDRESS-REGISTRY descr: RIPE NCC Whois Service origin: AS3333 admin-c: DK58 specpref: 1.2.3.4/32 type: OTHER descr: The wrld's most important HTTP server admin-c: ABC789 one could add bogon filter info as well: specpref: 10.0.0.0/8 ORLONGER type: BOGON RFC1918 descr: Privaqte Address Space not to be routed on public Internet admin-c: IANA The beauty of this is that those responsible can dynamically update it. Those who want to make filters or flap dampening configs can do so using their own policies. Somehow this idea never caught on. I am not sure why because noone pointed out obvious flaws with it. The only slghtly hard thing about this is to agree on an initial set of "types". However once can limit this set initially and periodically look at the "OTHER" type entries to identify useful new categories. Also there needs to be someone verifying that entries for the defined types really match that type and some access-control preventing anyone to create entries. For authorisation of changes standard RIPE DB mechanisms can be used. I am sure we can find someone to do this initially. My suggestion for an initial list of types is DNS ROOT DNS TLD WHOIS TLD WHOIS ADDRESS OTHER If there are two others who would like to join writing this up as a spec I will be happy to donate a few spare minutes to contribute and to edit it. If there are serious flaws with this, let's hear them. Daniel
specpref: 193.0.14.0/24 type: DNS ROOT descr: K Root Server admin-c: DK58
...
DNS ROOT DNS TLD WHOIS TLD WHOIS ADDRESS OTHER
LONGEST ALLOC PREFIX, under rir control, would address the discussions of automatic generation of prefix length filters. apologies, but the semantics of the two WHOIS entries are not obvious to me from the syntax. and i am willing to _help_ with a document. randy
At 12:54 PM 6/28/00, Randy Bush wrote:
specpref: 193.0.14.0/24 type: DNS ROOT descr: K Root Server admin-c: DK58
...
DNS ROOT DNS TLD WHOIS TLD WHOIS ADDRESS OTHER
LONGEST ALLOC PREFIX, under rir control, would address the discussions of automatic generation of prefix length filters.
I had thoght about that. In the RIPE database context this is more properly addressed by an atttribute of the corresponding inetnum object, e.g something like: inetnum: 217.0.0.0 - 217.255.255.255 netname: EU-ZZ-217 descr: RIPE NCC descr: European Regional Registry country: EU admin-c: NN32-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT min-alloc: /20 <============ changed: hostmaster@ripe.net 20000602 changed: hostmaster@ripe.net 20000615 source: RIPE
apologies, but the semantics of the two WHOIS entries are not obvious to me from the syntax.
Prefixes in which there are whois servers serving information about address allocations by RIRs (ADDRESS) or TLD name delegations (DNS). Rationale: When diagnosing network problems either of these are often needed, so they should remain reachable.
and i am willing to _help_ with a document.
Thanks. You'll get at least to proofread it if and when it is written. Daniel
On 2000-06-28T15:33:04, Daniel Karrenberg <Daniel.Karrenberg@ripe.net> said:
Prefixes in which there are whois servers serving information about address allocations by RIRs (ADDRESS) or TLD name delegations (DNS). Rationale: When diagnosing network problems either of these are often needed, so they should remain reachable.
I would say that these are best reflected by an attribute in the route (inetnum?) object. Sincerely, Lars Marowsky-Brie <lmb@suse.de> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl
LONGEST ALLOC PREFIX, under rir control, would address the discussions of automatic generation of prefix length filters. I had thoght about that. In the RIPE database context this is more properly addressed by an atttribute of the corresponding inetnum object, e.g something like: inetnum: 217.0.0.0 - 217.255.255.255 netname: EU-ZZ-217 descr: RIPE NCC descr: European Regional Registry country: EU admin-c: NN32-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT min-alloc: /20 <============ changed: hostmaster@ripe.net 20000602 changed: hostmaster@ripe.net 20000615 source: RIPE
it is not clear from your example how you expect me to compose the search which produces the table i derive manually today. do i use mnt-lower recurse down a tree from a known root? if so, it needs a left and right pointer, not just a single one. do i form a query for all ??-ZZ-*? randy, confused again in seattle
At 04:07 PM 6/28/00, Randy Bush wrote:
inetnum: 217.0.0.0 - 217.255.255.255 ... min-alloc: /20 <============
The reason I propose to put it in the inetnum is one of architectural cleanness. This is clearly an attribute describing a property of an address block. We have an object descibing an address block, so the attribute should go there.
it is not clear from your example how you expect me to compose the search which produces the table i derive manually today.
A number of possibilitites here: 1) to get it for each /8 foreach $slasheight in (1..255) whois -a -tinetnum $slasheight/8 | grep '^min-alloc:' [other granularities left as an exercise] 2) to get all min-allocs of certain sizes foreach $minalloc in (/16../24) whois -a -tinetnum -imin-alloc $minalloc I would expect anyone can set a min-alloc atribute on the inetnum objects they maintain, however small. One can of course check that the min-alloc is not larger than the block itself but that is about it. Theis means that with (2) you will have to filter out the objects that you wish to consider. This could be done by maintainer or block size. I think both of these, while not totally simple, are straightforward enough. Daniel
1) to get it for each /8
foreach $slasheight in (1..255) whois -a -tinetnum $slasheight/8 | grep '^min-alloc:'
[other granularities left as an exercise]
2) to get all min-allocs of certain sizes
foreach $minalloc in (/16../24) whois -a -tinetnum -imin-alloc $minalloc
what i want operationally to do what i do manually today is give me all min allocs which specify rir allocation policies. randy
Regardless of whether they are moving targets or not, I think if the document states something in a particular section, it should be correct. An appendix which stated "this could be an example configuration which the authors believe correct on date of publication" might make the casual reader and implementor more careful. However, I would agree creating a registry of these "special" networks would be a good idea. Ofcourse, like the Routing Registry, who is going to keep it up to date? A bad registration won't affect the connectivity of the special sites, so the only incentive for people is to "do the right thing". And that motivation varies from provider to provider. BTW, to your list of special prefixes, I'd add the prefixes which are identified in draft-manning-dsua-03.txt. I'm assuming the special prefixes would include not only the flap dampening exceptions, but prefixes which shouldn't appear on the Internet? philip -- At 12:14 28/06/00 +0200, Daniel Karrenberg wrote:
Any moving targets, such as prefixes for root NS connectivity, should be taken out of the document. A long time ago I have proposed to set up a registry for such prefixes roughly like this:
specpref: 193.0.14.0/24 type: DNS ROOT descr: K Root Server admin-c: DK58
specpref: 128.250.0.0/16 type: DNS TLD descr: AU TLD Server admin-c: RE18
specpref: 193.0.0.0/22 type: WHOIS ADDRESS-REGISTRY descr: RIPE NCC Whois Service origin: AS3333 admin-c: DK58
specpref: 1.2.3.4/32 type: OTHER descr: The wrld's most important HTTP server admin-c: ABC789
one could add bogon filter info as well:
specpref: 10.0.0.0/8 ORLONGER type: BOGON RFC1918 descr: Privaqte Address Space not to be routed on public Internet admin-c: IANA
The beauty of this is that those responsible can dynamically update it. Those who want to make filters or flap dampening configs can do so using their own policies.
Somehow this idea never caught on. I am not sure why because noone pointed out obvious flaws with it. The only slghtly hard thing about this is to agree on an initial set of "types". However once can limit this set initially and periodically look at the "OTHER" type entries to identify useful new categories. Also there needs to be someone verifying that entries for the defined types really match that type and some access-control preventing anyone to create entries. For authorisation of changes standard RIPE DB mechanisms can be used. I am sure we can find someone to do this initially. My suggestion for an initial list of types is
DNS ROOT DNS TLD WHOIS TLD WHOIS ADDRESS OTHER
If there are two others who would like to join writing this up as a spec I will be happy to donate a few spare minutes to contribute and to edit it. If there are serious flaws with this, let's hear them.
Daniel
participants (4)
-
Daniel Karrenberg -
lmb -
Philip Smith -
Randy Bush