- ipv6-wg - mailman.ripe.net

RE: [apnic-talk] Status field for inet6num objects
by Guy Davies 20 Jun '02

20 Jun '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Nigel Titley [mailto:nigel@titley.com] > > On Wed, 2002-06-12 at 07:11, Daniel Karrenberg wrote: > > At 06:00 AM 6/12/2002, Geoff Huston wrote: > > >However, the distinction between "ALLOCATED" and > "ASSIGNED" is perhaps a bit subtle. > > > > When these attributes were created, those particular words > were in deemed both descriptive and clear. > > Maybe the language concerned has shifted underneath in the > meantime ;-). > > As a native speaker of one of its dialects, would you make > a suggestion for improvement? > > Well actually as a native speaker of (another) of its dialects, > I've never considered the distinction of ALLOCATED and ASSIGNED to > be other than subtle. I'd much prefer DELEGATED and ASSIGNED or > some such. This may be a matter of taste however. I tend to agree with Nigel, although I'd go for something even plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know they're a bit verbose but they're absolutely clear ;-) It also makes clear that addresses assigned to an LIR in the role of END-USER are exactly that. That way, an individual who is struggling with English as a second language (or even their first language ;-) can be absolutely clear of the status of a range of addresses. Just my two pence... Regards, Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPQca4I3dwu/Ss2PCEQJv6ACeMa1ZbnoN3P7r6VaBANGPa1yXN9UAoMLQ cJpgKn6FvDPmyD1X02WLXJF3 =yl1x -----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.

8 8

RE: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>For me these two phrases, DELEGATED-TO-LIR and >ASSIGNED-TO-END-USER, hit the spot precisely! >excellent suggestion Guy! >Is it appropriate to request consideration of these terms as replacements >for ASSIGNED and ALLOCATED? Wouldn't it be a good idea to standardize the terminology with ARIN and others? In that case, the term LIR would be considered obscure and meaningless. Since all LIRs are service providers of some sort, either ISPs or an internal network service provider, I think that a standard terminology should try to use generic terms. That would mean either DELEGATED-TO-SVC-PROVIDER or DELEGATED-TO-NSP if you like acronyms (Network Service Provider). In any case, because the distinction between "allocated" and "assigned" has been unclear in the past and because there is a significant shift in terminology from "allocated" to "delegated" this change should be incorporated in an informational RFC. This document would help in clarifying that there is indeed a difference between the two states of an address block and would also help in promoting the use of this terminology amongst the community that deal with IP address delegations and assignments. DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear worldwide. Michael Dillon Network Product Engineering Radianz

2 1

Re: [apnic-talk] Status field for inet6num objects
by Geoff Huston 13 Jun '02

13 Jun '02

>To clarify, the values that APNIC would prefer to use are: > >ALLOCATED PORTABLE >ALLOCATED NON-PORTABLE >ASSIGNED PORTABLE >ASSIGNED NON-PORTABLE > >As I mentioned before, these values would be consistent with those in >IPv4 (which take effect in August when the migration to version 3 of the >RIPE database is complete). > >Comments? I would be in favour of this clarity in the field regarding PORTABLE and NON_PORTABLE. However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. regards, Geoff

1 0

Re: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>Allocation and assign do have definitions - could these be improved >to clarify the meaning? Or does 'delegate' simply convey a much >clearer intention with the address space? Delegation is clearer for two reasons. Firstly, it implies that the the delegator is passing on some responsibility for the address space. The organization receiving a delegation is responsible for managing and administering the addresses. In the case of an assignment, this is less true. For instance, ISPs regularly reassign addresses after a customer disconnects and everyone seems to understand that addresses assignments are controlled by the assigner and can be withdrawn. The second reason has more to do with psychology. Because the terms "allocation" and "assignment" are similar in meaning and visually similar, they are easily confused by a lot of people. They both begin with "a" followed by a double consonant and end with a latin suffix. Of course, clear definitions are always a good thing as well. Michael Dillon Network Product Engineering Radianz

1 0

RE: [apnic-talk] Status field for inet6num objects
by kevin.bates＠bt.com 12 Jun '02

12 Jun '02

seems better but not perfect - the important thing is to get all databases looking the same and using the same terms? strictly speaking it is not "ASSIGNED-TO-END-USER" its "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up pool and thus only " leased" for the duration of that connexion. > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. > > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) > > Daniel

2 1

RE: [apnic-talk] Status field for inet6num objects
by Geoff Huston 12 Jun '02

12 Jun '02

> > This is an excellent idea. However I would use > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > That way we clarify the subtle difference while > > maintaining consistency with existing documentation. > > > > (If I remember correctly the term DELEGATED was suggested at the time, > > but not used because of its usage in the DNS context as well as > > the connotation of total transfer of authority over the resource which > > is not quite the case.) To me "DELEGATED-TO-LIR" makes sense, as it infers that the process of further delegation can be used with sub-blocks and/or atomic units can be "ASSIGNED-TO-END-USERs with the inference that no further sub assignments are anticipated. Geoff

1 0

RE: [apnic-talk] Status field for inet6num objects
by Michel Py 12 Jun '02

12 Jun '02

> Anne Lord wrote: > There is no PI in IPv6. > This can't be said often enough. We are working on two new types of v6 addresses that are neither PA nor PI for multihoming. Please keep in mind that PA does not provide enough functionality; if no multihoming protocol is released in a timely manner you will inevitably have PI, or whatever you want to call everyone becoming a LIR. Michel.

1 0

Draft Minutes (v1) IPv6 wg RIPE42
by David Kessens 04 Jun '02

04 Jun '02

Please see below for the first version of the draft minutes of the IPv6 wg at the last RIPE meeting. I would like to thank the scribe for writing down the minutes. The minutes will be declared final by June 7th if there are no objections raised and/or major changes required. Thanks, David K. --- Draft Minutes of the IPv6 Working Group session of the RIPE 42 Meeting, 29 April - 3 May 2002 at the Krasnapolsky Hotel, Amsterdam, Netherlands. The session was held on May 2, 14:00 - 17:30 ----------------------------------- Chair: David Kessens Scribe: Rainer R|cker Attendees: 113 ----------------------------------- Agenda: 1st slot A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. IPv6 roadmaps of network equipment vendors a. Juniper (Jean-Marc Uze, Elise Gerich) b. Cisco (Simon Pollard) C. Global IPv6 routing table status (Gert Dvring) D. Tunnelbrokers & ipv6 in practice (Pim van Pelt) related discussion topic: do we prefer to use 6to4 instead of tunnelbrokers ?!? 2nd slot E. IPv6 Promotion Council Activities Overview (Kosuke Ito) F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? (Joao Luis Silva Damas, RIPE NCC) G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? (Joao Luis Silva Damas, RIPE NCC) related topic: 6to4 reverse delegations H. lbnamed Bug Discussion I. IPv6 allocation survey (Mirjam K|hne, RIPE NCC) J. Euro6IX and layer 3 IX addressing (Raffaele D'Albenzio) K. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) - French NIC initiative regarding DNSv6 deployment (Mohsen Souissi) L. LIR-WG session on IPv6 policy Z. AOB ======================== A: Scribe, Agenda bashing ======================== Two scribes from the RIPE NCC. One additional presentation from the tipster project was accepted for point K on the agenda. The Agenda was accepted. ======================== B. IPv6 roadmaps of network equipment vendors a. Juniper ======================== Jean Marc Uze (JMU) presented Junipers Roadmap for IPv6. The slides are available at Pim van Pelt (PVP): What about Filtering and OSPF6 ? JMU: OSPF6 for Junos will come in the second half of 2002 Filtering will come soon. ?: Are you working on 6-to-4 transition? JMU: Are there already applications that need it? ?: 6-to-4 relays will need it, these will be important for the users ?: What about 6PE? (MPLS over IPv6) JMU: Should be avoided on core routers, since it degrades performance. ?: Will you implement NAT/PAT for v6? JMU: Not on the short term. ======================== B. IPv6 roadmaps of network equipment vendors b. Cisco ======================== Simon Pollard (SP) presented Ciscos Roadmap for IPv6. The slides are available at Gert Dvring (GD): The IOS upgrade is not really free available - you need to buy the IP+ option package before you can make the upgrade. SP: This is true for the low-end platforms - but most people have IP+ anyway PVP: What about filtering and OSPF6. SP: Available - a beta of OSPFv3 will be out in October 2002. ?: What about Layer3 Switches? SP: They will come in Q3/2002 ?: Will there be a Ciso-PIX for IPv6? SP: This is planned for Q1/2003 ?: Is there 6PE and NAT/PAT for v6? SP: Yes, we have this for the PE-routers GD: IOS has become very large - you can't fit it into the small routers without upgrading Flash and Memory. Customers are not willing to spend money in order to upgrade. Make IOS smaller. An Image-size of 4MB would be good. SP: Customers will pay for the router-upgrade if they see the business drive of IPv6. However, Cisco is working on re-packaged IOS for the lower platforms. The memory-footprint will probably be 8 MB. GD: 4MB should be the target. ======================== C. Global IPv6 routing table status ======================== Gert Dvrings presentation is available at http://www.space.net/~gert/RIPE/R42-v6-table/ Conclusions: - Downstream filtering recommended - You should watch the announcements of your peers. PVP: 6bone has changed it's policy to give out /32 now, four of these prefixes should be visible. 15 are in the table. ?: Is there a canonical filter-list for IPv6 ? GD: Not yet. ?: Would you be up to maintain such a list? GD: I will discuss this with David Kessens and we should move the discussion on this topic to the mailing-list. === ;7777777;7777777;7777777 COFFEE BREAK ;7777777;7777777;7777777 10:35 - 10:50 ;7777777;7777777;7777777 === ?: Is it easy to filter unassigned ASNs ? GD: Technically this is possible but it's preferable to talk to the people that are making the mistakes. ======================== D. Tunnelbrokers & ipv6 in practice ======================== Pim van Pelts presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… PVP: Sixxs, a IPv6 tunnel-broker for LIRs in the RIPE-region is looking for participants that are willing to be a POP for this service. ?: What about the 6-to-4 tunnels? PVP: At the time we started, static tunneling was the only thing available. Today, if you run a 6-to-4 relay, it's easy for everyone to join, so it's also easy for everyone to abuse the service. If you host the relay, you also have to filter the incoming IPv4 traffic which is not easy. Attacks by script-kiddies on the next-hop of the relay (which is IPv4) are common today. DK: There have also been native V6-DoS-attacks, it's really scary. ======================== E. IPv6 Promotion Council Activities Overview ======================== Kosuke Ito's presentation can be found at ??? See also http://www.v6pc.jp/index_e.html - The audience had no questions or comments. ======================== F. IPv6 capable RR DNS servers - what is needed, what are the issues ?!? ======================== DK: IPv6 capable RR DNS Servers should be discussed in the LIR-WG. - the audience agreed ======================== G. IPv6 RR DNS - is it ip6.int or ip6.arpa? Why? Documented where? ======================== Joao Luis Silva Damas presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… The recommendation is to populate ip6.arpa and phase out ip6.int - but what is wanted and how shall we proceed? ?: Software currently relies on ip6.int - you can't just switch it off. ?: Can't we just duplicate the delegation-records? GD: A good solution would be a CNAME very high in the hierarchy DK: Can't we just do automatic delegation in both domains? Joao: ip6.int should be abandoned soon - if we duplicate it will not go away. GD: But older machines all use ip6.int. Joao: OK, for the time being both delegations are possible. But should it be done automatically or do we only delegate in ip6.int if someone really wants it? GD: RIPE NCC should investigate if it's possible to do away with ip6.int and make a solution with CNAMEs. Make some experiments and report at RIPE 43 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation. Wilfried Woeber: Automatic delegation for ip6.int and ip6.arpa appears the best solution, but if someone requests different delegations in ip6.arpa and ip6.int, RIPE NCC should not prevent this. Mohsen Suissis: RIPE NCC did this in the past, at least for 2002:0660::/35 both delegations were made. DK: RIPE NCC, could you investigate the possibilities? Joao: OK, we will do the automatic delegation in both trees by default and we will allow different configuration if the user wants it. ?: But would this approach not lead to inconsistent data in the two domains? DK: It's only reverse delegation, that should have no big impact. DK: OK, 6-to-4 reverse delegation will also happen in ip6.arpa. What about this? Joao: The draft on 6 to 4 DNS (draft-ietf-ngtrans-6to4-dns-00.txt) is not very specific. RIRs will do the delegation based on the IPv4 /8s that they are authoritative for, but anything else is not clear yet. DK: What about the 6bone addresses and ip6.arpa Joao: I am not familiar with that. DK: Could you investigate this and give a more specific presentation at RIPE 43? Joao: Sure. ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43 ======================== H. lbnamed Bug Discussion ======================== Francis Dupont explained that an updated version of lbnamed is available and urged everyone using lbnamed to update to the latest version. ======================== I. IPv6 allocation survey ======================== Mirjam K|hne announced that the survey will be published on the web. The presentation was not given in this session due to shortage of time. The survey is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… ======================== J. Euro6IX and layer 3 IX addressing ======================== Raffaele D'Albenzio's presentation is available at http://www.euro6ix.net/mantenimientos/e-doc_subidos/D1.1_Project_Presentati… (needs to be verified!) - The audience had no questions or comments. == DK reminded that there is not much time left. The time for each of the following presentations was restricted to less than 5 minutes. == ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond The Hungarian Tipster6 project ======================== Geza Turchanyi gave a short overview on the tipster6-project and provided some statistics on the v6-capability of several unix-distributions. (Sun, BSD, Linux) ======================== K. Developments/initiatives regarding IPv6 in the RIPE region and beyond French NIC initiative regarding DNSv6 deployment ======================== Mohsen Suissis presentation is available at http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe42-ipv6… Mohsen Suissis pointed out that currently not many TLD-Nameservers are native v6-speakers. AFNIC is willing to help other NICs to roll out v6 DNS. AFNIC also applied to become secondary for ip6.arpa. The request was submitted to IANA but nothing happened so far. ======================== L. LIR-WG session on IPv6 policy ======================== The iproposal for a global interim IPv6 Allocation Policy was accepted by the LIR-WG. ======================== Z. AOB ======================== Nothing reported ======================== Summary of actions arising from this meeting ======================== 42.1 ACTION on RIPE NCC: Investigate the CNAME solution for v6-reverse delegation in the ip6.int tree. 42.2 ACTION on RIPE NCC: Give an overview of 6-to-4 reverse delegation issues at RIPE 43

7 11

New IPv6 blcok allocated to RIPE NCC
by leo vegoda 04 Jun '02

04 Jun '02

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:0800::/23 from the IANA in May 2002. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC, Registration Services Assistant Manager

1 0

RE: New Document available: RIPE-233
by Michel Py 30 May '02

30 May '02

Havard, > Havard Eidnes wrote: > I have to ask a rhetorical question here, what is a "block" in > this context? > Is it a single routing announcement? Surely, it cannot be, > because the different root name servers are placed at different > points in the topology. The very purpose of placing them at different points is to have redundancy; so yes, for the same reason they must have different blocks. > I'll claim that the actual numeric sequence (or non-sequence) of > the IPv6 address blocks allocated to the root name servers do not > matter; the identity of the blocks will be well-known anyway, so > there is no robustness gain to be had from picking "obscure" or > "scattered" numbers. There is an advantage to scattered numbers, IMHO. Since they are scattered, nobody will try to aggregate them and suppress the specific announcements. Martian configs do happen; not often but they do. > I do however agree with those which have said that a root name server > should not have its address changed when it moves between RIR regions; > the whole point of this "special" assignment to the root name servers > is to avoid *any* renumbering because the DNS bootstrap data is > (currently) distributed in a static configuration file. There are (at least) two ways to achieve this: 1. Two-space systems (the servers would have a unique identifier and multiple changeable locators). 2. "special assignement" otherwise called PI. I think the RIRs have acted responsibly so far in not showing the bad example of allocating themselves a PI block. A short-term fix to this would be a two-space system where the locator initially assigned could be transformed into the identifier later. Michel.

1 0