idnits 2.17.1 draft-ietf-ngtrans-6bone-registry-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 35 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [Date], [FreeText], [RFC1035], [3], [4], [A-Z], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 104: '...arked [optional] MAY be present in an ...' RFC 2119 keyword, line 105: '...rked [mandatory] MUST be present in th...' RFC 2119 keyword, line 106: '...t are marked [multiple] MAY be present...' RFC 2119 keyword, line 107: '...s while attributes marked [single] MAY...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 270 has weird spacing: '...on: ftp ftp.n...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'FreeText' on line 304 -- Looks like a reference, but probably isn't: 'Date' on line 407 -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Experimental RFC: RFC 1876 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1924 (ref. '4') Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force David Kessens 2 Draft Nokia 3 Expires January 2001 5 The 6bone registry 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that other 14 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 This document describes the syntax of the RIPE database classes which 40 are used in the 6bone registry to support the operation of the 6bone 41 and therefore the introduction of ipv6. 43 Introduction 45 The syntax is based on the experience with the 'ftp' object 46 repository at the RIPE NCC created by Geert Jan de Groot and from 47 discussions on the 6bone mailing list. The general format that is 48 used follows the RPSL [1] specifications. 50 Several attribute name changes are made to the 'ftp' object to 51 faciliate a better integration (and reuse of already existing 52 attributes) in the RIPE database scheme. 54 The existing nearly-real time mirroring mechanism of the RIPE 55 database software allows for a fast distribution mechanism to other 56 (mirror) databases in a topologically closer position to the database 57 users. It is therefore satisfactory that the data can only be 58 updated at the 6BONE database repository [2]. This avoids conflicting 59 data in different databases as is currently the case with the ipv4 60 route and AS number clasess. 62 The following two classes are introduced and described in the 63 folowing chapters: 65 ipv6-site 66 inet6num 68 The following classes of the existing RPSL schema are used: 70 role 71 person 72 mntner 74 The ipv6-site class 76 This class describes the sites that are part of the 6bone. The 77 information stored in objects of this type contains operational 78 information regarding a site on the 6bone. The 'origin' attribute 79 contains the AS number of the site and the 'prefix' attributes 80 contains the route prefixes which are exported by the site to the 81 outside world. The 'tunnel' attribute describes tunneled links 82 between different 'ipv6-site's while the 'native' attribute describes 83 native ipv6 links between 'ipv6-site's. 85 Formal RIPE database template: 87 ipv6-site: [mandatory] [single] 88 origin: [mandatory] [single] 89 descr: [mandatory] [single] 90 location: [optional] [multiple] 91 country: [mandatory] [multiple] 92 prefix: [mandatory] [multiple] 93 application: [optional] [multiple] 94 tunnel: [optional] [multiple] 95 native: [optional] [multiple] 96 contact: [mandatory] [multiple] 97 remarks: [optional] [multiple] 98 url: [optional] [multiple] 99 notify: [optional] [multiple] 100 mnt-by: [optional] [multiple] 101 changed: [mandatory] [multiple] 102 source: [mandatory] [single] 104 Attributes that are marked [optional] MAY be present in an object 105 while attributes marked [mandatory] MUST be present in the object to 106 be valid. Attributes that are marked [multiple] MAY be present 107 multiple times in the objects while attributes marked [single] MAY 108 not be present in the object for more than one time. 110 Description and purpose of the attributes: 112 ipv6-site: 114 SiteTag is a short unique tag for the 'ipv6-site' to be used for 115 lookups and referrals of the object. 117 Syntax: 119 /^[A-Z\d][A-Z\-\d]*[A-Z\d]$/ && /[A-Z]/ 121 Example: 123 ipv6-site: NOKIA 125 origin: 127 OriginAS is the AS number of the AS of which the 'ipv6-site' is 128 part of. 130 Syntax: 132 /^AS\d+$/ 134 Example: 136 origin: AS226 138 descr: 140 Attribute describes the 'ipv6-site'. This attribute usually 141 contains information about the location of the 'ipv6-site' and a 142 full name of the site. 144 Syntax: 146 /^.*$/ 148 Example: 150 descr: Nokia 151 Mountain View 153 location: 155 LocationString contains the coordinates of the 'ipv6-site's 156 location. Multiple location strings can be provided on different 157 lines for sites that have multiple locations in the area. One can 158 use a domainname instead of LocationString if an RFC1876 LOC 159 record is present in DNS [3]. 161 Note that this attribute is unnecessary for DNS based databases 162 since DNS already has support for special location (LOC) records. 164 Syntax: 166 location: 171 Examples: 173 location: 37 49 S 144 58 E 200m 174 location: 42 21 43.952 N 71 5 6.344 W -24m 1m 200m 175 location: loiosh.kei.com 177 Full syntax is described in RFC1876. An excerpt follows below: 179 3. Master File Format 181 The LOC record is expressed in a master file in the following 182 format: 184 LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]] 185 {"E"|"W"} alt["m"] [siz["m"] [hp["m"] 186 [vp["m"]]]] ) 188 (The parentheses are used for multi-line data as specified in [RFC 189 1035] section 5.1.) 191 where: 193 d1: [0 .. 90] (degrees latitude) 194 d2: [0 .. 180] (degrees longitude) 195 m1, m2: [0 .. 59] (minutes latitude/longitude) 196 s1, s2: [0 .. 59.999] (seconds latitude/longitude) 197 alt: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) 198 siz, hp, vp: [0 .. 90000000.00] (size/precision in meters) 200 If omitted, minutes and seconds default to zero, size defaults to 201 1m, horizontal precision defaults to 10000m, and vertical 202 precision defaults to 10m. These defaults are chosen to represent 203 typical ZIP/postal code area sizes, since it is often easy to find 204 approximate geographical location by ZIP/postal code. 206 4. Example Data 208 ;;; ;;; note that these data would not all appear in one zone file 209 ;;; 211 ;; network LOC RR derived from ZIP data. note use of precision 212 defaults cambridge-net.kei.com. LOC 42 21 54 N 213 71 06 18 W -24m 30m 215 ;; higher-precision host LOC RR. note use of vertical precision 216 default loiosh.kei.com. LOC 42 21 43.952 N 217 71 5 6.344 W -24m 1m 200m 219 pipex.net. LOC 52 14 05 N 00 08 50 E 10m 221 curtin.edu.au. LOC 32 7 19 S 116 2 25 E 10m 223 rwy04L.logan-airport.boston. LOC 42 21 28.764 N 224 71 00 51.617 W -44m 2000m 226 country: ... 228 Specify here the country codes of the countries where your site is 229 located. 231 Example: 233 country: US 235 or 237 country: DK SE 239 prefix: 241 IPv6Prefix is a prefix that is announced to other ipv6-sites. 243 Syntax: 245 247 ValidIPv6Address is defined in [4]. 249 Example: 251 prefix: 5f0d:0500:c100::/64 253 application: [port[/protocol]] 255 This attribute describes the different services available on the 256 site. The services are the same as described in the 257 '/etc/services' plus 'ping' More services might be added later on. 259 Hostname is the DNS hostname of the host that provides the service 260 and a port number and protocol type may be specified for services 261 that don't run on the standard port. 263 Syntax: 265 /^\S+\s+[a-zA-Z\-]+(\.[a-zA-Z\-])*\s+\d+(\/udp|\/tcp))?$/ 267 Examples: 269 application: ping pinghost.nokia.net 270 application: ftp ftp.nokia.net 272 tunnel: in -> 273 [FreeText] 275 This attribute defines a tunnel of Protocol1 in Protocol2 from 276 address src to address dst. It is desired that src and dst address 277 are domainnames, but ipv4 addresses are also allowed. You only 278 need to define your side of the tunnel. The other end should be 279 present in the object of the other party's site object. Note that 280 tunnels should in general be configured symmetrically along both 281 end-points and only be present in the object if they are actually 282 configured and working at both ends. 284 Currently (only) the following type of tunnels are accepted: 286 tunnel: IPv6 in IPv4 -> 287 [FreeText] 289 It is expected that more possibilities will be added later. 291 Currently defined protocols are: IDRPv6, BGP4+, RIPv6, STATIC 292 Syntax checking will not be done on this field to allow for newer 293 and fast implementations of other protocols. 295 Domainnames are used for greater flexibility. It makes it for 296 example trivial to obtain the ipv6 or ipv4 address from DNS if 297 needed. 299 Example: 301 tunnel: IPv6 in IPv4 tbc5000-18.tbit.dk -> unvea.denet.dk 302 TELEBIT IDRPv6 304 native: -> [FreeText] 306 This attribute defines a native ipv6 link between two ipv6 sites. 308 All definitions are the same as in the the 'tunnel:' attribute 309 with the following exception: src and dest are domainnames and 310 point to an ipv6 address, or if no domainname is configured, an 311 ipv6 address may be used. 313 Example: 315 native: tbc5000-18.tbit.dk -> unvea.denet.dk TELEBIT IDRPv6 317 contact: 319 This is the contact information of the site. Use a valid NIC 320 handle that you received when creating an entry for your personal 321 data in one of the regional registries databases. A 6bone registry 322 NIC handle can be assigned if you didn't already have a NIC handle 323 registered. There is no need to duplicate the personal data that 324 is already registered in one of the regional registries databases, 325 existing NIC handles can be used. It is recommended to refer to 326 NIC handles of 'role's rather then 'person's since 'role's contact 327 information don't need to be changed when personnel changes occur 328 in the 'ipv6-site's organization. 330 Example: 332 contact: DK13-RIPE 334 Note for DNS databases: 336 References for DNS style databases can be defined as follows: 338 - use a valid NIC-handle that points to an entry in a whois Internet 339 registry database 341 - use the following syntax: 343 contact: YourName (DomainNameOfTextRecordWithYourContactObject) 345 - the ipv6-site object has a personal data entry attached in DNS 346 (separated by an empty record with a line number only) and the 347 contact entry has the same value as the name of the person. 349 person: [mandatory] [single] 350 address: [mandatory] [multiple] 351 phone: [mandatory] [multiple] 352 fax-no: [optional] [multiple] 353 e-mail: [optional] [multiple] 354 remarks: [optional] [multiple] 355 changed: [mandatory] [multiple] 357 remarks: 359 Put here any information that might be interesting for the other 360 people at the 6bone to know about or use it for site specific 361 information. Also 'not yet accepted new functionality' to the 362 objects can be put here (temporarely). 364 Many people use this to report about the status of their site; is 365 it in implementation phase, is it up and running or are there 366 still techincal problems. 368 Syntax: 370 /^.*$/ 372 Example: 374 remarks: operational since July 5, 1996 375 remarks: happy to add new tunnels upon request. 376 remarks: 6bone-router.cisco.com carries all ipv6 routes. 378 url: 380 Put here any useful URLs that are of interest for your site 382 Example: 384 url: http://www.iol.unh.edu 386 notify: 388 Put here an email address of an organization or person that will 389 be informed about updates to the object. 391 Example: 393 notify: david@iprg.nokia.com 395 mntner: 397 Put here a reference to an existing 'mntner' object. A 'mntner' 398 object is used to protect objects. It can disallow third-parties 399 to make changes and/or will send a notification mail to inform the 400 maintainer of an object that changes have been made. The 'mntner' 401 is part of the RPSL database schema. 403 Example: 405 mnt-by: MNT-NOKIA 407 changed: [Date] 409 Use this attribute to show who was resposible for a 410 change/addition of the object and the date on which it took 411 effect. You may use more changed attribute to reflect the change 412 history of the object. 414 The date field has the following format: YYYYMMDD. More 'changed:' 415 attributes can be specified to show a history of changes. The 416 database software will automatically add the current local date of 417 the database software if no date is specified. 419 Example: 421 changed: davidk@iprg.nokia.com 19960923 422 changed: davidk@iprg.nokia.com 424 source: 6BONE 426 This field is always the same for now. It describes the place 427 where the object can be updated and is stored. 429 Example: 431 source: 6BONE 433 The inet6num class 435 This class describes the allocation of ipv6 address space. The 436 class is derived form the ipv4 address allocation class 'inetnum' 437 as used in the RIPE database schema. The information stored in 438 objects of this type contains administrative information regarding 439 address space allocated to an organization. Adress space prefixes 440 described in an 'inet6num' are not necessarily seen on the 6bone 441 network. The address space might have been aggregrated in shorter 442 prefixes which are announced by the transit provider of the 443 organization that got the address space allocated. These prefixes 444 are described in the 'prefix' attributes the 'ipv6-site' object. 446 The 'inet6num' attribute contains the prefix that was allocated to 447 the organization described in the 'descr' and 'netname' attribute. 448 The 'rev-srv' attribute contains optional information about the ip 449 numbers of the the sites reverse dns servers. The 'status' 450 attribute is automatically generated and tells whether the 451 allocation is (pseudo)TLA, SLA or NLA space. 453 Formal RIPE database template: 455 inet6num: [mandatory] [single] 456 netname: [mandatory] [single] 457 descr: [mandatory] [single] 458 country: [mandatory] [multiple] 459 admin-c: [mandatory] [multiple] 460 tech-c: [mandatory] [multiple] 461 rev-srv: [optional] [multiple] 462 status: [generated] [single] 463 remarks: [optional] [multiple] 464 notify: [optional] [multiple] 465 mnt-by: [optional] [multiple] 466 mnt-lower: [optional] [multiple] 467 changed: [mandatory] [multiple] 468 source: [mandatory] [single] 470 Description and purpose of the attributes: 472 'descr', 'country', 'notify', 'mnt-by' and 'changed' are already 473 described and explained in the 'ipv6-site' section. 475 inet6num: 477 IPv6Prefix is a prefix that is allocated to the organization as 478 described in the 'descr' and 'netname' attribute. 480 Syntax: 482 484 ValidIPv6Address is defined in [4]. 486 Example: 488 inet6num: 5f0d:0500:c100::/64 490 netname: 492 Syntax: 494 /^[A-Z][A-Z\d\-]*$/ 496 Example: 498 netname: NOKIA-IPV6-NETWORK 500 admin-c: 501 tech-c: 502 'admin-c' is the administrative contact of the 'inet6num' while 503 'tech-c' is the technical contact. is described under 504 'contact' in the 'ipv6-site' section. 506 rev-srv: 508 Nameservers that are in use for the reverse name resolution of the 509 allocated ipv6 address space. 511 status: 513 This field is automatically generated based on the allocated 514 prefix. The 6bone address space 'status' field is prefixed by a 515 'p' since address space is actually allocated as a pseudo TLA, NLA 516 or SLA. 518 mnt-lower: 520 Put here a reference to an existing 'mntner' object as described 521 in the 'mnt-by' section of the 'ipv6-site' class. In contrast to 522 the 'mnt-by' attribute, this attribute protects against the 523 creation of allocation objects directly below the 'inet6num' in 524 which it is used in the 'inet6num; prefix hierarchy. This allows 525 administrators of ipv6 address space to manage their portion of 526 the ipv6 address space and to make sure that third parties cannot 527 create objects using their address space. 529 Example: 531 inet6num: 5f0d:0500:c100::/48 532 mnt-by: MNT-NOKIA 534 Only 'MNT-NOKIA' can create new 'inet6num' objects in this space 535 of the ipv6 address hierarchy: 5f0d:0500:c100::/48, 536 5f0d:0500:c100::/49, 5f0d:0500:c100::/50 etc.. However, as soon as 537 an object has been created the 'mntner' of the new object can 538 update or delete the his/her ipv6 address space allocation, and if 539 desired so add a 'mnt-lower' attribute to his/her allocation to 540 suballocate the allocated address space further. 542 source: 544 As described in the 'ipv6-site' section. However, other 545 s might exist for address space that has been 546 allocated by one of the regional address space registries or IANA. 548 Security considerations 550 There are no security implications since this draft solely describes 551 a data representation. Security of the 6bone registry itself is 552 dependant on the operation of the registry, the quality of the 553 software implementation used and the use by the users of proper 554 'mntner' objects, which is not specified in this document but is part 555 of the RPSL specification. 557 Acknowledgments 559 The first version of the ipv6-site object for the 6bone registry was 560 created by Geert Jan de Groot and David Kessens. 562 References 564 [1] C. Alaettinoglu et. al., RFC 2622, June 1999. 566 [2] http://whois.6bone.net/ 568 [3] C. Davis, P. Vixie, T. Goodwin and I. Dickinson, RFC 1876, January 1996 570 [4] R. Elz, RFC 1924, April 1996 572 Document editor's address: 574 David Kessens 575 Nokia 576 313 Fairchild Drive 577 Mountain View, CA 94043 578 USA 579 david@iprg.nokia.com