July 2002 - lir-wg - mailman.ripe.net

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

> -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Thursday, July 11, 2002 6:41 AM > To: lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > > > A customer can have a peer with the default transit, which > aggregates the > > adresspace from the customer, and the customer can have > other peerings > > via some ix:es, and the customer could perform transit > to/from the ix:es > > to the default transit, in this scenario the customer MUST > have a public > > AS, which you will not see in the public space, since > removing private > > AS in the AS-path will result in somewhat unpredictable > behaviour if there > > are several private AS involved at the customer premises. > > Yes, but this still makes the AS publicly visible. > > Best regards, > > - kurtis - > As we already seen some real examples, the correct USED ASN will only be seen from their upstream (it is public no matter what) but not outside to other peers (may due to CIDR, may due to inactive route). This has nothing to do with private ASN but make it impossible to enforce the proposed policy just by looking at the RIS. I agree that RIPE NCC need to have an ASN revoke policy but just can NOT based on the RIS info only. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

1 0

A quick question.
by Stephen Burley 11 Jul '02

11 Jul '02

HI I have a question about the RIPE meetings. Due to the nature of the business we are all in at the moment (myself probably more than others ATM), would it not be possable the webcast the RIPE meetings allowing input from outside via phone, email, or other means. The reason i ask this is that the meetings are open to all IF and its a big IF you can attend the meeting in the exotic locations we have met in the past. I am not against the meetings moving about and a meeting in Amsterdam will be just as hard to get to for some one in North Africa as a meeting in North Africa for those in Amsterdam. What i am asking is could we make it more accessable to those who for what ever reason (ahem) can not make the meeting, otherwise it might not have the coverage and diversity of people having input. Just a thought. Regards, Stephen Burley WorldCom EMEA Hostmaster SB855-RIPE

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

Several examples: 1. Confederate AS : only the top level AS number is announced by design, all member ASes should not be visible outside the confederate. 2. CIDR aggregate : If customer's address got aggregated by upstream ISP, usually you won't see their AS numbers from the upstream ISP's CIDR (especially for those people like to filter on allocation boundary). Technically I don't see how RIPE NCC can possibly find all the ASes that are originated but invisible to the public route server. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] > Sent: Tuesday, July 09, 2002 3:26 PM > To: Lu, Ping > Cc: 'wtremmel(a)vianetworks.com'; 'Matthew Robinson'; Wilfried > Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 02:01:26PM -0400, Lu, Ping wrote: > >This has nothing to do with the private AS-number. > > > >If an AS number existed in our backbone (public to CW) but not to > >RIPE NCC's route server. Will that be considered NOT USED ? > > Could you possibly provide us with more examples in which > circumstances someone > may need to use AS number from the PUBLIC range instead of > using AS number from > PRIVATE range in the case when there is no need to advertise > any prefixes > originated by such AS-number to the PUBLIC Internet (i.e. > this AS number will > never be visible outside of some private network)? > > I can remind only one case - some kind of IX, are used by > some ASes to > exchange routing information localy. Generaly speaking IX-AS > may not be > visible from PUBLIC, but in the most cases, especialy if we > are talking > about enterprise networks, same results may be achieved by > using AS-number > from private range. > > By way of proof - AS15645 is used for the public Ukrainian > Internet-Exchange. > Appearance of any prefixes originated by this AS outside of > IX members networks > violates IX rules and should be avoided. > > Lets summarise - there ARE circumstances when AS number from > PUBLIC range may > be requested and used being invisible from the majority of > the Internet. > > It would be nice to mention that in policy and provide some examples. > > -- > Regards, > Vladimir. >

5 7

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

Definitely there is AS number being used within our backbone but not advertised to public network. So the AS number should be allowed to be registered but not advertised the same way as IP address is treated. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Matthew Robinson [mailto:matthew@crescent.org.uk] > Sent: Tuesday, July 09, 2002 9:57 AM > To: Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > In the documentation for address space provision is made for > assigning addresses to organisations that will NEVER be > connected to the Internet but require uniqueness from private > address space. > > Whilst I can't think of a specific example to apply to AS > numbers, should this uniqueness be extended to AS numbers > that do not show up in the routing table but are very much on-line? > > I also recon 3 months to get online although given the length > of time it can take a big comapany to integrate a small one > lets say 12 months for returning. > > Kind regards > > Matthew >

6 8

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

[snip] > > Yes. I had recently a lengthy "discussion" with RIPE hostmasters about > a multihomed AS of a customer. Primary upstream with us, secondary > upstream with AS702. Using 702:80 community to lower localpref within > 702, making the backup link real backup. As 702 announces best path > (which is via their peering to us to the customer), RIPE was unable to > see the 702 backup announcement anywhere. Explanation of BGP basics by > myself were not understood or ignored. Or both. They also did not > contact AS702 for simple confirmation of what I've told them. > Took three > or four emails to get that finally sorted out. Whom do I bill > those 30-45 > minutes to (rhetoric question)? ;-> > This is another good example why AS number is originated but invisible to the global routing table. > End of the story was that they finally said "We have found AS21197 in > the import policy of AS702 and going to close this ticket now." :-]]] > > IF they really want to enforce ASN assignment policy, they > should REALLY > have to have a clue about BGP. Looking at some random looking glasses > or RIS data and not understanding it is NOT enough for a > policy-enforcing agency. And someone should explain them the > difference > between a looking glass and a traceroute server. > > Let's say... Halabi as compulsary lecture for hostmasters who have to > evaluate ASN assignment policy compliance. :-) > > > Regards, > Daniel > It is almost impossible for RIPE NCC to look into all upstream ISP's routing table and verify that an AS is being used properly. If RIPE NCC can't find a way to reduce the false alarm of AS verification, the enforcement will become more likely an harassment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 2

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

See the inline comment. Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Vladimir A. Jakovenko [mailto:vovik@lucky.net] > Sent: Tuesday, July 09, 2002 4:16 PM > To: Lu, Ping > Cc: 'wtremmel(a)vianetworks.com'; 'Matthew Robinson'; Wilfried > Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: Re: [lir-wg] AS Number Policy > > > On Tue, Jul 09, 2002 at 03:57:49PM -0400, Lu, Ping wrote: > >Several examples: > > > >1. Confederate AS : only the top level AS number is > announced by design, all > >member ASes should not be visible outside the confederate. > > What is the reason (or advantage) in using AS numbers from > PUBLIC pool for > confederate ASes, if they are not visible outside of confederation? > Why do you think confederate AS should belong to the same company ? And you can force one of them to use private AS ? > >2. CIDR aggregate : If customer's address got aggregated by > upstream ISP, > >usually you won't see their AS numbers from the upstream ISP's CIDR > >(especially for those people like to filter on allocation boundary). > > Again - what is the reason in using AS numbers from PUBLIC pool for > customer's ASes if this ASes will never appear outside of upstream ISP > network? > Huh ? RIPE NCC always recommends that the end user should use PA address from the upstream ISP so only the less specific CIDR (with ISP's AS number) will appear in the GLOBAL routing table and the more specific prefixes (with end user's AS number) WON'T POLLUTE the GLOBAL routing table.Now in order to show their assigned AS numbers, end user will have to POLLUTE the GLOBAL routing table with their more specific prefixes. > I may imagine only one case - customer's AS peering with public IX. > Yes, IX is another example that AS is originated but not visible in the GLOBAL routing table. > >Technically I don't see how RIPE NCC can possibly find all > the ASes that are > >originated but invisible to the public route server. > > Agree. But there are also administrative possibilites. > > -- > Regards, > Vladimir. >

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 11 Jul '02

11 Jul '02

> -----Original Message----- > From: Christopher Sharp [mailto:ripe-lir-wg@chriss.net] > Sent: Wednesday, July 10, 2002 11:32 AM > To: lir-wg(a)ripe.net > Cc: Lu, Ping > Subject: Re: [lir-wg] AS Number Policy > > > On Wed, 10 Jul 2002 11:22:29 -0400, "Lu, Ping" <PLu(a)cw.net> wrote: > > >I don't think to blackholing traffic is a good idea, especially > >when bandwidth means money in today's internet. > > I agree. Neither do I think the community should be paying > to provide the > bandwidth for such a service. > > Encouraging people to filter out these netblocks/ASNs does > make it very hard to > re-allocate them in the short term. However, most people who > maintain good > bogon filters also update them frequently, so hopefully would > remove any such > filters in plenty of time for ASNs to be re-allocated after > 12/24/36 months. > The major ISPs usually update these filters daily and if the tier-1 ISPs all have these filters then smaller ISPs don't have to filter them again. > >RIRs should publish a list to include all the offending prefixes and > >the major ISPs will be more than happy to apply the prefix filter to > >block transit to those prefixes. There is already an IANA > bogon filter > >floating around. > > This was my suggestion in a nutshell. I believe the most > commonly observed > bogon list is maintained by Rob Thomas > (http://www.cymru.com/Documents/bogon-list.html) > draft-iana-special-ipv4-03 is > IANA's most comprehensive list of special use netblocks > (http://www.ietf.org/internet-drafts/draft-iana-special-ipv4-03.txt) > Maybe we can have an official filter-set object so people don't have to update these info manually. > >RIPE NCC could add a filter-set object, let's say > FLTR-RIPE-RESERVED-IPV4 > >and > >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, > >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. > >Then all major ISPs could apply these filter to block > transit traffic for > >these > >prefixes. > > This sounds excellent but doesn't cover prefixes IANA have > not yet allocated to > an RIR. This is why I would encourage frequent sharing of > this data with the > networking community and especially the maintainers of public > bogon lists on > which many people filter. > In the IANA assigned RIR range, we still need RIRs to tell us what range under their authority are not allocated yet thus should be filtered. > >Blocking is a better idea than blackholing.... > > C. > Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net

3 2

RE: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

At 11:22 AM 10-07-02 -0400, Lu, Ping wrote: > > -----Original Message----- > > From: Berislav Todorovic [mailto:beri@kpnqwest.net] > > Sent: Wednesday, July 10, 2002 6:38 AM > > To: Hank Nussbacher > > Cc: Christopher Sharp; lir-wg(a)ripe.net > > Subject: Re: [lir-wg] AS Number Policy > > > > > > On Wed, 10 Jul 2002, Hank Nussbacher wrote: > > > > >> I'd like to make a suggestion. Since these ASNs and IP > > blocks are the > > >> property of the RIRs, and since organizations are cybersquatting on > > >> these resources why shouldn't these RIRs advertise these > > IP blocks and > > >> ASNs themselves and blackhole them to their routers? > > > > I'd like to back this idea! > > > > However, even if ICANN itself suddenly gets stroken by > > lightning of technical > > wisdom and starts announcing unused /8's - that won't prevent > > offenders from > > announcing more specific routes, will it? On the other hand, > > announcing /24's > > will really pollute the global routing table, which is big > > enough anyway. > >I don't think to blackholing traffic is a good idea, especially >when bandwidth means money in today's internet. > >RIRs should publish a list to include all the offending prefixes and >the major ISPs will be more than happy to apply the prefix filter to >block transit to those prefixes. There is already an IANA bogon filter >floating around. As mentioned earlier by someone, I'd hate to get an ASN or IP block that happened to be in the past inside such a published list. You can bet that somewhere, someplace, sometime, such a filter list will not be updated and will end up blocking someone inadvertantly. -Hank >RIPE NCC could add a filter-set object, let's say FLTR-RIPE-RESERVED-IPV4 >and >ARIN should have a FLTR-ARIN-RESERVED-IPV4 object, >APNIC also should have a FLTR-APNIC-RESERVED-IPV4 object. >Then all major ISPs could apply these filter to block transit traffic for >these >prefixes. > > > > > > Still, having a service like Paul Vixie's AS7777 would help a > > lot: an ISP > > willing to receive blackhole routes would bring a route > > server on their > > backbone, establish a peering session with "IANA blackhole > > AS" and use the > > routes to construct filters etc. > > > > Regards, > > Beri > > > >Blocking is a better idea than blackholing.... > >Ping Lu >Cable & Wireless USA >Network Tools and Analysis Group >W: +1-703-292-2359 >E: plu(a)cw.net

1 0

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>Lets see the following example: > > +-----------+ +-------+ > | AS-UPLINK | | AS-IX | > +---------o-+ +o------+ > | | > +o-----------o+ > | AS-CUSTOMER | > +-------------+ > >[ ... ] > >Should AS-CUSTOMER be considered as multihomed? Definitely, as they'd probably have more then one eBPG session, and probably a different routing policy. I don't see any reason to treat "customer" status (i.e. packets shipped for money) different from "peering" status (i.e. packets shipped for "free"). >-- >Regards, >Vladimir. Wilfried.

3 3

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>1. How long does the community believe it is reasonable to take to > bring an AS 'on-line'? What is the definiton of "on-line" here? Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6 6

Re: [lir-wg] AS Number Policy
by Hank Nussbacher 10 Jul '02

10 Jul '02

On Tue, 9 Jul 2002, Christopher Sharp wrote: > On Tue, 09 Jul 2002 12:57:46 +0300, Hank Nussbacher <hank(a)att.net.il> wrote: > > >At 11:53 AM 09-07-02 +0200, leo vegoda wrote: > >>1. How long does the community believe it is reasonable to take to > >> bring an AS 'on-line'? > >3 months. > > > >>2. After how many months of not being in use should an AS be > >> returned? > >3 months. > > > >3.After how many months of being single-homed should an AS be returned? > >9-12 months. > > I agree with the time scales for unused ASes and think Hank has raised a very > valid point about those in use.I would be in favour of a 6 month timescale for > return of these 'unless intent can be proven to re-multi-home within 3 months'. > > Producing an easily enforceable policy covering those AS in use may be a little > more complicated.I think most offenders who have become single-homed are > likely to ignore warnings of an approaching return date until it arrives.I > suggest a 6 month period of warning followed by a formal request for return and > a 3 months for them to depreciate use of the AS and return it.The net result > is a 9 month period of return with plenty of warning to depreciate use of a > single-homed AS. > > C. > The problem I foresee will be removing an ASN. RIPE has a policy of not changing mntner objects or overriding them so if the ASN just ignores RIPEs emails and continues to use the ASN - then what? And even if RIPE manages to have a procedure for removing an ASN against the will of the organization it was allocated to, what is to stop the organization to continue to use it? Those that follow NANOG have seen a case of AS5757 which is not listed in any DB and it has been announced for the past 3 years. Hank Nussbacher

5 7

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 10 Jul '02

10 Jul '02

>Again - what is the reason in using AS numbers from PUBLIC pool for >customer's ASes if this ASes will never appear outside of upstream ISP >network? How do you define "never" in today's or tomorrow's Internet ?! ;-) -w

2 1

RE: [lir-wg] AS Number Policy
by Lu, Ping 09 Jul '02

09 Jul '02

This has nothing to do with the private AS-number. If an AS number existed in our backbone (public to CW) but not to RIPE NCC's route server. Will that be considered NOT USED ? Ping Lu Cable & Wireless USA Network Tools and Analysis Group W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: Wolfgang Tremmel, WT5-RIPE [mailto:wtremmel@vianetworks.com] > Sent: Tuesday, July 09, 2002 1:27 PM > To: Lu, Ping; 'Matthew Robinson'; Vladimir A. Jakovenko > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > Subject: RE: [lir-wg] AS Number Policy > > > If it is nowhere advertised you could use a privat AS-number... > > Wolfgang > > > > -----Original Message----- > > From: owner-lir-wg(a)ripe.net > [mailto:owner-lir-wg@ripe.net]On Behalf Of > > Lu, Ping > > Sent: Tuesday, July 09, 2002 6:55 PM > > To: 'Matthew Robinson'; Vladimir A. Jakovenko > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > Subject: RE: [lir-wg] AS Number Policy > > > > > > Definitely there is AS number being used within our backbone but not > > advertised to public > > network. So the AS number should be allowed to be registered but not > > advertised the same way > > as IP address is treated. > > > > Ping Lu > > Cable & Wireless USA > > Network Tools and Analysis Group > > W: +1-703-292-2359 > > E: plu(a)cw.net > > > > > > > > > -----Original Message----- > > > From: Matthew Robinson [mailto:matthew@crescent.org.uk] > > > Sent: Tuesday, July 09, 2002 9:57 AM > > > To: Vladimir A. Jakovenko > > > Cc: Wilfried Woeber, UniVie/ACOnet; lir-wg(a)ripe.net > > > Subject: Re: [lir-wg] AS Number Policy > > > > > > > > > In the documentation for address space provision is made for > > > assigning addresses to organisations that will NEVER be > > > connected to the Internet but require uniqueness from private > > > address space. > > > > > > Whilst I can't think of a specific example to apply to AS > > > numbers, should this uniqueness be extended to AS numbers > > > that do not show up in the routing table but are very > much on-line? > > > > > > I also recon 3 months to get online although given the length > > > of time it can take a big comapany to integrate a small one > > > lets say 12 months for returning. > > > > > > Kind regards > > > > > > Matthew > > > >

2 1

Re: [lir-wg] AS Number Policy
by Wilfried Woeber, UniVie/ACOnet 09 Jul '02

09 Jul '02

Beri, I agree with most of your statements, in particular your assessment of the "credibility" of RIS data *) to base such important decisions on - as well as the suggestion to accept a "statement of use" as sufficient. However, doing so leaves me with a cost vs. benefit ratio for the whole exercise! I guess there is a considerably big number of AS#s the RIR/LIR tree does not have authority over (or rather: distribution predating existence of those structures). And, unless we have a _clear consensus_ that going through this exercise can avoid the introduction of AS#s with more than 16 bits _altogether_ (or at least extends the lifetime of the 16bit version *considerably*), the whole issue might be mute... Wilfried. *) this is not questioning the usefulness or utility of RIS data, but it seems to be the wrong tool for obtaining a reliable reading for this context. And I guess it's pretty easy to fake... ______________________________________________________________________ Date: Tue, 9 Jul 2002 15:33:53 +0200 (CEST) From: Berislav Todorovic <beri(a)kpnqwest.net> To: leo vegoda <leo(a)ripe.net> CC: lir-wg(a)ripe.net Subject: Re: [lir-wg] AS Number Policy On Tue, 9 Jul 2002, leo vegoda wrote: >> We would be grateful if the community would clarify the policy so >> that it is clear when an unused AS number should be returned to >> the pool. Let's try to summarize things a bit: this issue is not only about numbers and timescale. A complete AS number revokation policy must comprise of 4 components: * Audit policy on AS number usage. * Clear definition of policy violation. * Revoking AS numbers from customers violating AS number usage policies. * Reusing revoked AS numbers. RIPE NCC reserves the right to perform periodic audits on AS number usage and take appropriate actions if necessary, to enforce compliance with ripe-245 and RFC 1930. RIPE NCC will use RIS to check if an AS number is used with compliance with those documents. RIPE NCC must never consider RIS as the ultimate source and must always raise an audit ticket towards the LIR and/or an end customer of an AS before taking any further action. A possible violation of the policy happens if an AS number: (1) Does not appear in the routing table at all: (a) Assigned, but never appeared (startup case) within S months. (b) Missing completely for more than D months. (2) Appears in the routing table via a single AS path for more than M months. While we can discuss on the values of S, D and M special care must be taken on revokation and reusal policy. For (1a) - there seems to be a consensus that S would be 3 months. For (1b) - just to be on the safe side D should be at least 6 months. For (2) - also to be on the safe side M should be at least 12 months. If a violation if found, RIPE NCC reserves the right to notify the LIR that requested the AS number about violation and ask them to provide additional evidence that the AS number is still in valid use. A clear statement from the LIR that the AS number is still used in compliance with the policy MUST be enough to close the audit ticket. No further action should be taken in that case. If there is no response from the LIR, RIPE NCC should contact the admin-c and tech-c specified in the aut-num object. In a lot of cases an AS number is issued by a LIR that doesn't have anything to do with the customer any more. If no response counting from notification date is received from the end customer: * In the case (1a) - within 3 months, * In the case (1b) - within 6 months, * In the case (2) - within 12 months the AS number may be revoked by RIPE NCC. AS number reusage policy - a revoked AS number may be reused after certain period of time, defined as: * In the case (1a) - 3 months after it is revoked from the end customer. * In the case (1b) - same time period that elapsed between revokation date and initial assignment date of the AS number. That should give enough time to all people to cleanup their configurations, policies etc. * In the case (2) - same as (1b). Regards, Beri --------------------------------------------------------------------------------

1 0

AS Number Policy
by leo vegoda 09 Jul '02

09 Jul '02

Dear Colleagues, Within the RIPE community the AS policy (ripe-245) is based upon RFC 1930. The RIPE policy states that "a network [is required] to be multihomed for an AS number to be assigned". However, there is no clear policy on returning unused AS numbers to the pool. We would be grateful if the community would clarify the policy so that it is clear when an unused AS number should be returned to the pool. Specific questions we would like to ask are: 1. How long does the community believe it is reasonable to take to bring an AS 'on-line'? 2. After how many months of not being in use should an AS be returned? Due to a lack of time in the LIR Working Group session at RIPE 42 (May 2002) we were not able to discuss the community's policy for AS numbers. We would like to raise the issue now so that there is ample time for a discussion before RIPE 43, on Rhodes, in September. We welcome the community's input on this policy matter. Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

7 7

RE: [lir-wg] Discussion Summary: Status field for inet6num object s
by Guy Davies 08 Jul '02

08 Jul '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would prefer RIR-LIR-ALLOCATED, LIR-SUB-ALLOCATED and LIR-USER-ASSIGNED (or similar) if we must keep ALLOCATED and ASSIGNED in the descriptions. I don't think that it is immediately clear from the proposals below whether LIR-ALLOCATED is allocated by an LIR or to an LIR. Regards, Guy > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, July 08, 2002 1:42 PM > To: leo vegoda > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net; db-wg(a)ripe.net; > sig-db(a)apnic.net; > policy-db(a)apnic.net; apnic-talk(a)apnic.net > Subject: Re: [lir-wg] Discussion Summary: Status field for inet6num > objects > > > Hi, > > On Mon, Jul 01, 2002 at 06:21:24PM +0200, leo vegoda wrote: > > The RIPE NCC needs to implement a new status attribute for the > > inet6num object to reflect the new policy agreed by the RIPE, > > ARIN and APNIC communities. > > > > The RIPE NCC suggested the following new status attributes for > > the inet6num objects: > > > > - RIR-ALLOCATED > > (For allocations made by an RIR to an LIR) > > > > - LIR-ALLOCATED > > (For allocations made by an LIR or an LIR's downstream > > customer > > to another downstream organisation) > > > > - ASSIGNED > > (For assignments made to End User sites) > > I haven't seen any replies to this so far. > > I want to express that I like this proposal. It doesn't introduce > any new and yet-undefined terms, but makes clear what the status of > a given network is. > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: > 45809 (45931) > > SpaceNet AG Mail: netmaster(a)Space.Net > Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 > 80807 Muenchen Fax : +49-89-32356-299 > -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPSmLLo3dwu/Ss2PCEQIJdQCeOKDqqTLKCuB+o3pWMj/XJ41QJMQAnROW EWRBiRI4rPpF9DRbhrxYcK0S =Rab7 -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

2 1

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

New Document available: RIPE-244
by RIPE NCC Document Announcement Service 05 Jul '02

05 Jul '02

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-244 Title: Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region Author: Joao Luis Silva Damas, Leo Vegoda Date: 4 July 2002 Format: PS=13515 TXT=4723 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Accessing the RIPE document store --------------------------------- You can access the "Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region" in HTML format at the following URL: http://www.ripe.net/ripe/docs/rev-del.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-244.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-244.txt plain text version

2 1

New IPv6 policy implemented on 1 July 2002
by Paul Rendek 01 Jul '02

01 Jul '02

Dear Colleagues, The RIPE NCC is pleased to announce the implementation of the new IPv6 policy effective 1 July 2002. This IPv6 policy was accepted by consensus at RIPE 42 and is common to all Regional Internet Registry communities - APNIC, ARIN, and the RIPE NCC. The new policy replaces the provisional IPv6 policy launched in 1999. The IPv6 Policy documentation is available from the RIPE document store at: http://www.ripe.net/ripe/docs/internet-registries.html The current set of IPv6 documents are: - IPv6 Address Allocation and Assignment Policy - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - Supporting Notes for the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region - Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Key points of the new IPv6 policy you should be aware of: - The minimum allocation size is /32; - LIRs currently holding a /35 have the option of expanding their allocation to a /32 on request; - In 2002, no additional fees are charged for IPv6 address space in the RIPE NCC service region. The RIPE NCC IPv6 web pages can be found at: http://www.ripe.net/IPv6/ Regards, Paul Rendek Communications Manager RIPE NCC

2 1