From adrian at ripe.net Tue Oct 4 14:41:11 2005 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Tue, 04 Oct 2005 14:41:11 +0200 Subject: [address-policy-wg] 2005-09 New Policy Proposal Message-ID: <200510041241.j94CfBgL031603@birch.ripe.net> PDP Number: 2005-09 Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries Dear Colleagues A new RIPE Policy has been proposed and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-09.html We encourage you to review this proposal and send your comments to before 1 November 2005. After this date, we will prepare a draft RIPE Document. We will let you know when this is available. Regards Adrian Bedford RIPE NCC From adrian at ripe.net Wed Oct 5 10:03:13 2005 From: adrian at ripe.net (RIPE NCC Policy Coordinator) Date: Wed, 05 Oct 2005 10:03:13 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal Message-ID: <200510050803.j9583DgL023686@birch.ripe.net> PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues, A proposed change to RIPE Document ripe-ripe-267 is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html We encourage you to review this proposal and send your comments to before 2 November 2005. After this date, we will prepare a draft RIPE document. We will let you know when this is available. There is a new mailing list for announcing policy proposals and tracking them through the policy development process. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce Regards Adrian Bedford RIPE NCC From jorgen at hovland.cx Wed Oct 5 10:43:33 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 5 Oct 2005 10:43:33 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <200510050803.j9583DgL023686@birch.ripe.net> Message-ID: <200510050843.j958hX3R024120@mail03.hipercom.no> >>End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (only one subnet is anticipated for the End Site). I have a general question: If the allocation is less than /64, lets say 10 addresses, can I allocate IPv6 addresses from our /64 pool instead of allocating a /64 in the RIPE DB to the customer? Or do I have to allocate a /64 in the DB and then give the customer the 10 addresses? I guess I can assign a /64 to the customer in the DB anyway, but the customer will never get the entire /64, only the 10 addresses. Cheers, Joergen Hovland -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of RIPE NCC Policy Coordinator Sent: 5. oktober 2005 10:03 To: policy-announce at ripe.net Cc: Kurtis Lindqvist; Hans Petter Holen; address-policy-wg at ripe.net; gih at apnic.net Subject: [address-policy-wg] 2005-08 New Policy Proposal PDP Number: 2005-08 Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Dear Colleagues, A proposed change to RIPE Document ripe-ripe-267 is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-08.html We encourage you to review this proposal and send your comments to before 2 November 2005. After this date, we will prepare a draft RIPE document. We will let you know when this is available. There is a new mailing list for announcing policy proposals and tracking them through the policy development process. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce Regards Adrian Bedford RIPE NCC From gert at space.net Wed Oct 5 10:47:15 2005 From: gert at space.net (Gert Doering) Date: Wed, 5 Oct 2005 10:47:15 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <200510050843.j958hX3R024120@mail03.hipercom.no> References: <200510050803.j9583DgL023686@birch.ripe.net> <200510050843.j958hX3R024120@mail03.hipercom.no> Message-ID: <20051005084715.GN5931@Space.Net> Hi, On Wed, Oct 05, 2005 at 10:43:33AM +0200, J?rgen Hovland wrote: > >>End Users are assigned an End Site assignment from their LIR or ISP. The > size of the assignment is a local decision for the LIR or ISP to make, using > a minimum value of a /64 (only one subnet is anticipated for the End Site). > > I have a general question: > If the allocation is less than /64, lets say 10 addresses, can I allocate > IPv6 addresses from our /64 pool instead of allocating a /64 in the RIPE DB > to the customer? Or do I have to allocate a /64 in the DB and then give the > customer the 10 addresses? > I guess I can assign a /64 to the customer in the DB anyway, but the > customer will never get the entire /64, only the 10 addresses. Why should anyone want to give a customer 10 IPv6 addresses, and *not* a full /64? This would be very much against the spirit of IPv6 - "have enough addresses, and no questions asked". Inside an ISP's /32, there are 4 billion /64s. More than enough for your customer base, how large it may be. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Wed Oct 5 12:04:20 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 5 Oct 2005 12:04:20 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <20051005084715.GN5931@Space.Net> Message-ID: <200510051004.j95A4K3R027248@mail03.hipercom.no> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering [Ger Doering] Why should anyone want to give a customer 10 IPv6 addresses, and *not* a full /64? [J?rgen Hovland] I can think of a few reasons that would directly affect us now: * Internal marketing and/or policy reasons. * Limit the amount of abuse. * It isn?t possible with todays ethernet technology to use an entire /64 on the same LAN, MAC addresses are 48bits wide. Private customers only have one LAN link to us. Even if the MAC addresses were to be expanded into 96bit, the probability of MAC address collision most likely still is far too high. * Limitations in the contract making it reasonable to limit the amount of IP addresses you get, like "you are only allowed to connect 10 cameras to the internet". * We might want to sell a "cheaper" version of a better product. * It would result in a DoS if we didn?t limit the DHCP pool per link to something that our hardware is capable of doing. So the full /64 will never be used. * The product isn't capable of more than N links (machines). A thought: Security is about giving access to what you need, not what you can get. [Ger Doering] This would be very much against the spirit of IPv6 - "have enough addresses, and no questions asked". [J?rgen Hovland] I don't quite see the similarity between "having enough addresses" and "allocating the proper amount of addresses for the product you are buying", so I believe the spirit is still there. There will be less technical limitations in the future, but the other reasons will still remain. Cheers, Joergen Hovland From woeber at cc.univie.ac.at Wed Oct 5 12:12:40 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 05 Oct 2005 11:12:40 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <200510050803.j9583DgL023686@birch.ripe.net> References: <200510050803.j9583DgL023686@birch.ripe.net> Message-ID: <4343A718.4090708@cc.univie.ac.at> RIPE NCC Policy Coordinator wrote: > PDP Number: 2005-08 > Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy Proposing a bit of word-smithing: " Rationale: [ ... ] As a consequence of that, LIRs will need far more address space, depleting the available pool of addresses at an accelerated rate and reducing the lifetime of the IPv6 protocol." Proposed replacement text: As a consequence of that, LIRs and ISPs will distribute (to End Sites) IPv6 addresses in blocks much greater than presumably necessary for an average end site - thus depleting the pool of unallocated or unassigned IPv6 addresses at an accelerated speed. Why? I have a particular problem with the assertion that the "lifetime" of the protocol is reduced! The protocol itself will remain valid anyway, we would just have to modify the procedures for distributing the addresses. And the inclusion of "unallocated or unassigned" IPv6 addresses: because formally the pool of available addresses is of fixed size. Thanks for consideration! Wilfried. From gert at space.net Wed Oct 5 12:32:17 2005 From: gert at space.net (Gert Doering) Date: Wed, 5 Oct 2005 12:32:17 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <200510051004.j95A4K3R027248@mail03.hipercom.no> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> Message-ID: <20051005103217.GR5931@Space.Net> Hi, On Wed, Oct 05, 2005 at 12:04:20PM +0200, J?rgen Hovland wrote: > [J?rgen Hovland] > I can think of a few reasons that would directly affect us now: > > * Internal marketing and/or policy reasons. That's a very bad reason. > * Limit the amount of abuse. How does limiting the number of addresses you hand out limit the amount of abuse? > * It isn?t possible with todays ethernet technology to use an entire /64 on > the same LAN, MAC addresses are 48bits wide. Private customers only have one > LAN link to us. Even if the MAC addresses were to be expanded into 96bit, > the probability of MAC address collision most likely still is far too high. The laws of physics prevents 2^64 machines from connected to anything (today). But that's totally missing the point. Please read up on IPv6 fundamentals, how IPv6 autoconfiguration works, and why a /64 on LAN interfaces is generally thought to be a good thing. > * Limitations in the contract making it reasonable to limit the amount of IP > addresses you get, like "you are only allowed to connect 10 cameras to the > internet". This has nothing to do with the number of addresses you hand out. If you give them 10 addresses, they will connect 100 cameras (over USB or whatever) to a single IP host. What did you gain? Nothing. > * We might want to sell a "cheaper" version of a better product. Limiting the number of IPv6 address is just going to break things, but not making the product cheaper (to the contrary, you have much more work). If you want a low-end product, reduce the bandwidth, etc. > * It would result in a DoS if we didn?t limit the DHCP pool per link to > something that our hardware is capable of doing. So the full /64 will never > be used. That's what IPv6 autoconfiguration is for. You don't have to worry about DHCP pool size and memory and what not. Also your math is seriously flawed - if you think your DHCP pool is run out of memory, think how much *space* you need to staple 2^64 machines. A rough calculation leads to "only the RJ45 plugs (no cables) for 2^64 machines will weigh 184467440737095516 kilograms"... > * The product isn't capable of more than N links (machines). So what does this have to do with the number of addresses? > A thought: > Security is about giving access to what you need, not what you can get. Security has nothing to do with breaking established standards for IPv6 address assignment. Security has *nothing* to do with the number of IPv6 addresses - "security against *what*?". Using security as the "I don't know any other argument, and management always like if we claim things are more secure that way" killer argument doesn't work. > [Ger Doering] > This would be very much against the spirit of IPv6 - "have enough addresses, > and no questions asked". > > [J?rgen Hovland] > I don't quite see the similarity between "having enough addresses" and > "allocating the proper amount of addresses for the product you are buying", > so I believe the spirit is still there. The proper amount for any (!) LAN segment is a /64 today. Just read the RFC. There are specific exceptions for single-host connections with no LAN behind (a /128 is OK). *This* policy item is about "will a /56 be sufficient for customers with multiple LANs, or do we need a /48 for it". > There will be less technical limitations in the future, but the other > reasons will still remain. None of these make any sense. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Wed Oct 5 13:11:03 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 5 Oct 2005 13:11:03 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> Message-ID: <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> ----- Original Message ----- From: "Gert Doering" Gert, I think you are missing my point. Our products may issue max N addresses per link from dhcp defined by the product specifications. Can I allocate 10 IPv6 addresses to a customer from our own pool, or does the customer need its own record in the DB ? If so, _must_ this allocation be a /64 even though the customer will only use 10 addresses? [ ] Yes. [ ] No. [ ] Don't know. Please don't bring stateless autoconfiguration into this discussion. We are not running it. > > Security has *nothing* to do with the number of IPv6 addresses - > "security against *what*?". > Security has to do with everything. Never think otherwise. Cheers, Joergen Hovland From gert at space.net Wed Oct 5 13:31:23 2005 From: gert at space.net (Gert Doering) Date: Wed, 5 Oct 2005 13:31:23 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> Message-ID: <20051005113123.GS5931@Space.Net> Hi, On Wed, Oct 05, 2005 at 01:11:03PM +0200, J?rgen Hovland wrote: > Gert, I think you are missing my point. > Our products may issue max N addresses per link from dhcp defined by the > product specifications. > Can I allocate 10 IPv6 addresses to a customer from our own pool, or does > the customer need its own record in the DB ? If so, _must_ this allocation > be a /64 even though the customer will only use 10 addresses? > > [ ] Yes. > [ ] No. > [ ] Don't know. The IPv6 end user assignment policies are pretty strict in that regard. There is no option to give "10 addresses" to a user - period. When becoming LIR, you've signed that you'll follow the RIPE policies - and this is established RIPE policy. So the whole question is moot. [..] > >Security has *nothing* to do with the number of IPv6 addresses - > >"security against *what*?". > > Security has to do with everything. Never think otherwise. So please explain how giving users less IP addresses brings security benefits (user tracking comes to mind, but that can be done just fine by /64). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Wed Oct 5 14:28:15 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 5 Oct 2005 14:28:15 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> Message-ID: <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> ----- Original Message ----- From: "Gert Doering" >> Our products may issue max N addresses per link from dhcp defined by the >> product specifications. >> Can I allocate 10 IPv6 addresses to a customer from our own pool, or does >> the customer need its own record in the DB ? If so, _must_ this >> allocation >> be a /64 even though the customer will only use 10 addresses? >> >> [ ] Yes. >> [ ] No. >> [ ] Don't know. > > The IPv6 end user assignment policies are pretty strict in that regard. > > There is no option to give "10 addresses" to a user - period. When > becoming > LIR, you've signed that you'll follow the RIPE policies - and this is > established RIPE policy. > > So the whole question is moot. > I apologise if this is moot, but an answer would really be appreciated. This becomes a problem with private users as it already is today. We can't store data about every single private user into a public database, and there might also be issues regarding the privacy act. It breaks the "true spirit of IPv6"; "have enough addresses, and no questions asked". So basically we have a policy that is no or little different to the existing IPv4 policy, and private end-users can still only get one single address? Or am I totally wrong? How can I give 10, and only 10, addresses to a private customer without allocating the customer its own /64 ? Joergen Hovland From leo at ripe.net Wed Oct 5 14:40:44 2005 From: leo at ripe.net (leo vegoda) Date: Wed, 5 Oct 2005 14:40:44 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> Message-ID: On Oct 5, 2005, at 2:28 pm, J?rgen Hovland wrote: [...] >> The IPv6 end user assignment policies are pretty strict in that >> regard. >> >> There is no option to give "10 addresses" to a user - period. >> When becoming >> LIR, you've signed that you'll follow the RIPE policies - and this is >> established RIPE policy. >> >> So the whole question is moot. You need to register a network prefix in an inet6num, rather than an address range. The closest you could get to 10 addresses is 16, which would be a /124, I think. > I apologise if this is moot, but an answer would really be > appreciated. > This becomes a problem with private users as it already is today. > We can't store data about every single private user into a public > database, and there might also be issues regarding the privacy act. > It breaks the "true spirit of IPv6"; "have enough addresses, and > no questions asked". Would there be any real value in registering private users in Whois? How likely is it that the end user could provide assistance to whoever contacted them? The registration for the network containing the IPv4 /32 on my home ADSL connection shows my ISP's contact information. If I took an IPv6 service from them, I'd expect their contact information to be in that, too. Regards, -- leo vegoda Registration Services Manager RIPE NCC From jorgen at hovland.cx Wed Oct 5 14:58:58 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 5 Oct 2005 14:58:58 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> Message-ID: <00c401c5c9ac$8cce37d0$c0dea8c0@hipercom.local> ----- Original Message ----- From: "leo vegoda" > I apologise if this is moot, but an answer would really be appreciated. > This becomes a problem with private users as it already is today. We > can't store data about every single private user into a public database, > and there might also be issues regarding the privacy act. It breaks the > "true spirit of IPv6"; "have enough addresses, and no questions asked". >Would there be any real value in registering private users in Whois? How >likely is it that the end user could provide assistance to whoever >contacted them? So I can internally allocate 10 IPv6 addresses from our RIPE allocated /64, "IPv6 customer DSL pool", and give it to the private customer? I don't have to assign the customer itself a direct allocation? Thank you for your input. Joergen Hovland From gert at space.net Wed Oct 5 15:23:20 2005 From: gert at space.net (Gert Doering) Date: Wed, 5 Oct 2005 15:23:20 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> Message-ID: <20051005132320.GY5931@Space.Net> Hi, On Wed, Oct 05, 2005 at 02:28:15PM +0200, J?rgen Hovland wrote: > >>product specifications. > >>Can I allocate 10 IPv6 addresses to a customer from our own pool, or does > >>the customer need its own record in the DB ? If so, _must_ this > >>allocation > >>be a /64 even though the customer will only use 10 addresses? > >> > >>[ ] Yes. > >>[ ] No. > >>[ ] Don't know. > > I apologise if this is moot, but an answer would really be appreciated. The answer is "the RIPE policies have no answers how to do things that are in violation of the RIPE policies" - and assigning 10 IPv6 addresses is against the policy. > Or am I totally wrong? How can I give 10, and only 10, addresses to a > private customer without allocating the customer its own /64 ? What you can do, if you insist, is to allocate a /64, and block all but 10 addresses out of the block - this would follow the policies to the letter, if not the spirit. As for documentating the resulting /64: this is a very interesting issue, and this is an open debate "how much personal data must/can/must not be stored in the RIPE database". The policy (RPE-267) says: ------------ quote --------------- 3.3. Registration Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws. (more in 5.5) ------------ quote --------------- This can be interpreted as "you register it in an internal database, and if someone from the RIPE hostmaster is asking for allocation details, you provide all relevant data to the RIPE NCC" - and it is frequently done that way in IPv4 already. The RIPE database would then carry an umbrella object, stating what you do with the space ("this space is used for /64 assignments to end users") and whom to contact in case of questions or problems ("abuse at ...", etc.). The policy is a bit vague here, admitted. Most important is that people "out there" know what the address space is used for, and that you can show documentation to the RIPE NCC in case they come asking. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Wed Oct 5 15:25:36 2005 From: gert at space.net (Gert Doering) Date: Wed, 5 Oct 2005 15:25:36 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <00c401c5c9ac$8cce37d0$c0dea8c0@hipercom.local> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> <00c401c5c9ac$8cce37d0$c0dea8c0@hipercom.local> Message-ID: <20051005132536.GZ5931@Space.Net> Hi, On Wed, Oct 05, 2005 at 02:58:58PM +0200, J?rgen Hovland wrote: > So I can internally allocate 10 IPv6 addresses from our RIPE allocated /64, > "IPv6 customer DSL pool", and give it to the private customer? I don't have > to assign the customer itself a direct allocation? You can't "assign" an "allocation". Allocations are RIR->LIR, assignments LIR->Customer. If you give IPv6 address space to customers, you're *doing* assignments, and your company signed that you're going to do that according to policy (which says "/128, /64, or /48 - no other choices permitted, unless a /48 is provable too small"). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gih at apnic.net Wed Oct 5 14:42:07 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 05 Oct 2005 22:42:07 +1000 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <4343A718.4090708@cc.univie.ac.at> References: <200510050803.j9583DgL023686@birch.ripe.net> <4343A718.4090708@cc.univie.ac.at> Message-ID: <6.2.0.14.2.20051005224055.02a26f80@kahuna.telstra.net> Yes, I can see your point, and agree with it. regards, Geoff At 08:12 PM 5/10/2005, Wilfried Woeber, UniVie/ACOnet wrote: >RIPE NCC Policy Coordinator wrote: > > > PDP Number: 2005-08 > > Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy > >Proposing a bit of word-smithing: > >" Rationale: >[ ... ] >As a consequence of that, LIRs will need far more address space, depleting >the available >pool of addresses at an accelerated rate and reducing the lifetime of the >IPv6 protocol." > >Proposed replacement text: >As a consequence of that, LIRs and ISPs will distribute (to End Sites) >IPv6 addresses in >blocks much greater than presumably necessary for an average end site - >thus depleting the >pool of unallocated or unassigned IPv6 addresses at an accelerated speed. > >Why? >I have a particular problem with the assertion that the "lifetime" of the >protocol is >reduced! The protocol itself will remain valid anyway, we would just have >to modify the >procedures for distributing the addresses. > >And the inclusion of "unallocated or unassigned" IPv6 addresses: because >formally the pool >of available addresses is of fixed size. > > >Thanks for consideration! >Wilfried. From jorgen at hovland.cx Wed Oct 5 15:40:41 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Wed, 5 Oct 2005 15:40:41 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> <20051005132320.GY5931@Space.Net> Message-ID: <00fc01c5c9b2$60d26510$c0dea8c0@hipercom.local> ----- Original Message ----- From: "Gert Doering" To: "J?rgen Hovland" Cc: "Gert Doering" ; Sent: Wednesday, October 05, 2005 3:23 PM Subject: Re: [address-policy-wg] 2005-08 New Policy Proposal > Hi, > > On Wed, Oct 05, 2005 at 02:28:15PM +0200, J?rgen Hovland wrote: >> >>product specifications. >> >>Can I allocate 10 IPv6 addresses to a customer from our own pool, or >> >>does >> >>the customer need its own record in the DB ? If so, _must_ this >> >>allocation >> >>be a /64 even though the customer will only use 10 addresses? >> >> >> >>[ ] Yes. >> >>[ ] No. >> >>[ ] Don't know. >> >> I apologise if this is moot, but an answer would really be appreciated. > > The answer is "the RIPE policies have no answers how to do things that > are in violation of the RIPE policies" - and assigning 10 IPv6 addresses > is against the policy. > >> Or am I totally wrong? How can I give 10, and only 10, addresses to a >> private customer without allocating the customer its own /64 ? > > What you can do, if you insist, is to allocate a /64, and block all but > 10 addresses out of the block - this would follow the policies to the > letter, if not the spirit. > > As for documentating the resulting /64: this is a very interesting issue, > and this is an open debate "how much personal data must/can/must not > be stored in the RIPE database". > > The policy (RPE-267) says: > > ------------ quote --------------- > 3.3. Registration > > Internet address space must be registered in a registry database > accessible to appropriate members of the Internet community. This > is necessary to ensure the uniqueness of each Internet address and > to provide reference information for Internet troubleshooting at > all levels, ranging from all RIRs and IRs to End Users. > > The goal of registration should be applied within the context of > reasonable privacy considerations and applicable laws. > > (more in 5.5) > ------------ quote --------------- > > This can be interpreted as "you register it in an internal database, > and if someone from the RIPE hostmaster is asking for allocation > details, you provide all relevant data to the RIPE NCC" - and it is > frequently done that way in IPv4 already. > > The RIPE database would then carry an umbrella object, stating what > you do with the space ("this space is used for /64 assignments to > end users") and whom to contact in case of questions or problems > ("abuse at ...", etc.). > > The policy is a bit vague here, admitted. > > Most important is that people "out there" know what the address space > is used for, and that you can show documentation to the RIPE NCC in case > they come asking. This is very useful information. I now know that I have to assign (thanks for the correction) a minimum of /64 to every single customer if they need two or more addresses, and that I can hide their personal data (private users) in the public database when doing so. Thank you, Joergen Hovland From denis at ripe.net Wed Oct 5 16:27:27 2005 From: denis at ripe.net (Denis Walker) Date: Wed, 05 Oct 2005 16:27:27 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> Message-ID: <4343E2CF.4080307@ripe.net> leo vegoda wrote: > On Oct 5, 2005, at 2:28 pm, J?rgen Hovland wrote: > > [...] > >> I apologise if this is moot, but an answer would really be appreciated. >> This becomes a problem with private users as it already is today. We >> can't store data about every single private user into a public >> database, and there might also be issues regarding the privacy act. >> It breaks the "true spirit of IPv6"; "have enough addresses, and no >> questions asked". > > Can I ask a different question here? I have only seen the RIPE Whois Database from the RIPE NCC side. I have never worked for an ISP/LIR so I am not sure how you use all of the data contained in the Database. Does anyone actually use the addresses and phone numbers from person objects? Or is all communication done these days by e-mail? The address and phone attributes are mandatory and e-mail is optional in a person object. Is this the wrong way round for the way the data is used today? Just as a suggestion, perhaps address and phone details should only be mandatory in organisation and role objects and optional in person objects. Then you are more likely to be listing company information rather than individual information. Perhaps this would be less of a privacy issue. regards denis walker Software Engineering Department RIPE NCC > Would there be any real value in registering private users in Whois? > How likely is it that the end user could provide assistance to > whoever contacted them? > > The registration for the network containing the IPv4 /32 on my home > ADSL connection shows my ISP's contact information. If I took an IPv6 > service from them, I'd expect their contact information to be in > that, too. > > Regards, > From steffann at nederland.net Wed Oct 5 16:52:16 2005 From: steffann at nederland.net (Sander Steffann) Date: Wed, 5 Oct 2005 16:52:16 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <4343E2CF.4080307@ripe.net> Message-ID: <2B1A983EDCEC3447B22632B64F7264600B7525@bill.office.computel.nl> Hi, > Does anyone actually use the addresses and phone numbers from person > objects? Or is all communication done these days by e-mail? I never use address or phone information from the whois database. I can Imagine situations where they would be useful though... > The address and phone attributes are mandatory and e-mail is optional in > a person object. Is this the wrong way round for the way the data is used > today? In my case it is. > Just as a suggestion, perhaps address and phone details should only be > mandatory in organisation and role objects and optional in person objects. Sounds good to me. I think that in most cases the address in a person object will be the address of the company anyway... - Sander From pim at bit.nl Wed Oct 5 16:58:04 2005 From: pim at bit.nl (Pim van Pelt) Date: Wed, 5 Oct 2005 16:58:04 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <4343E2CF.4080307@ripe.net> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> <4343E2CF.4080307@ripe.net> Message-ID: <20051005145804.GB28357@localhost.localdomain> On Wed, Oct 05, 2005 at 04:27:27PM +0200, Denis Walker wrote: | Does anyone actually use the addresses and phone numbers from person | objects? Or is all communication done these days by e-mail? I occasionally use the phone and faxnumbers. | The address and phone attributes are mandatory and e-mail is optional in | a person object. Is this the wrong way round for the way the data is | used today? I don't think so, no. Not every customer of ours actually has or uses e-mail. Telephonenumbers are somewhat more common knowledge. Also, telephonenumbers are more intrusive so if one's complete IT infrastructure is failing or causing trouble, I'd rather use phone. | Just as a suggestion, perhaps address and phone details should only be | mandatory in organisation and role objects and optional in person | objects. Then you are more likely to be listing company information | rather than individual information. Perhaps this would be less of a | privacy issue. This makes sense to me. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E) From andrea at inet.it Wed Oct 5 16:59:23 2005 From: andrea at inet.it (Andrea Borgato) Date: Wed, 05 Oct 2005 16:59:23 +0200 Subject: [address-policy-wg] RIPE 51 - Address Policy WG Agenda (Draft) Message-ID: <5.1.0.14.2.20051005165223.04e9dcf0@pop.inet.it> Hello to everybody. Here in the following you can find Address Policy WG final draft of agenda. Regards, Andrea Borgato - Address Policy WG co-chair ----------------------------- CUT HERE ----------------------------- RIPE 51 - Address Policy Working Group Agenda (Draft) When: Wednesday, October 12, 2005, 14:00 - 15:30 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 50: http://www.ripe.net/ripe/wg/address-policy/r50-minutes.html B. Policy overview - Regional policy overview -- status of the PDP and transition to the PDP -- summary of the status of the current regional proposals started under the "beta test of the PDP" and now in "official PDP" http://www.ripe.net/ripe/policies/proposals/ - Global policy overview -- Status of the IPv4 Global Policy -- Status of the IPv6 Global Policy C. Policy proposal: #2005-01: IPv4-HD-Ratio Action on: HPH D. Policy proposal: #2005-02: TLD Anycast Allocation Policy Action on: Andreas Baess / Leo Vegoda (short update and current status) E. Policy proposal: #2005-03: IPv6 initial allocation criteria Action on: Andy Furnell / Leo Vegoda (current status and go ahead with discussion from mailing list) F. Policy proposal: #2005-04: definition of an "end site", Eric Schmidt (this definitely needs time for discussion - 15minutes?) G. Policy proposal: #2005-09 "global IPv6 distribution: ICANN/IANA->RIRs" (short update, now formally run through the PDP) H. Policy proposal: #2005-08 (Kurtis Lindqvist, Geoff Huston - RIPE IPv6 change of endsite allocations from /48 to /56) (need time for discussions) Z. Any other Business ----------------------------- CUT HERE ----------------------------- From hank at efes.iucc.ac.il Thu Oct 6 06:45:14 2005 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 6 Oct 2005 06:45:14 +0200 (IST) Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <4343E2CF.4080307@ripe.net> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> <4343E2CF.4080307@ripe.net> Message-ID: On Wed, 5 Oct 2005, Denis Walker wrote: Yes, we (il.isoc) use it occasionally. When we are revoking a customer's ASN or IP range due to any number of reasons (failure to be multihomed, for example), we will try email. If that fails we try calling up the phone number on record. If that fails, we send registered snail mail to the address on record. Therefore, I do see value in retaining those fields. -Hank > Does anyone actually use the addresses and phone numbers from person > objects? Or is all communication done these days by e-mail? > > The address and phone attributes are mandatory and e-mail is optional in > a person object. Is this the wrong way round for the way the data is > used today? From Michael.Dillon at btradianz.com Thu Oct 6 12:42:28 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 6 Oct 2005 11:42:28 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal Message-ID: > Would there be any real value in registering private users in Whois? > How likely is it that the end user could provide assistance to > whoever contacted them? Finally we are getting to the heart of the question which is about administrative procedure, i.e. policies, not about technology. The technology specifies that a "network" should be assigned a /64 but this thing called a "network" may not be an Ethernet broadcast domain. Different people will do different things with devices and this will lead them to use different address allocation strategies. For instance, consider an RS-232 cable daisychained through a factory with modems to handle the signal strength amplification when the signal gets too strong. Imagine 10 devices attached to this daisy chained RS 232 cable which use IPv6 to communicate. One might consider this a network or one might not. Is this decision a public policy decision or not? It really depends on where one puts the boundary between the public domain of the RIR and the private domain of the end user. Where should this boundary be? Is the current definition of the boundary too fuzzy? Does the RIR database contain more detail than it should because of the fuzziness of this boundary? Is the current definition of the boundary too tightly aligned with the 1990's world of ISPs and end users where ISPs use PDH and SDH networks while end users use Ethernet? What should go in the RIR database? What should stay out of the database because it is nobody else's business? --Michael Dillon From Michael.Dillon at btradianz.com Thu Oct 6 12:44:32 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 6 Oct 2005 11:44:32 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal Message-ID: > The answer is "the RIPE policies have no answers how to do things that > are in violation of the RIPE policies" - and assigning 10 IPv6 addresses > is against the policy. Assigning 10 IPv6 addresses is *NOT* against RIPE policy! It may come as a surprise to those of you who do not speak English as a native language, but the word "assign" is a synonym of the word "allocate" and both have a very general meaning of distributing something to multiple recipients. The fact that RIR policies use these synonyms in specific and distinct ways does not change the fact that anyone who learns English as a language of communication will learn that these two words mean the same thing and can be substituted for one another. Even worse (Horrors!) these two words can be used in business outside of the context of the RIRs. ISPs can allocate circuit bandwidth to customers, assign them to router ports, distribute IP addresses to them, etc. Inside the business he can certainly assign 10 addresses to his customer, however the very fact that he is choosing to allocate the customer 10 addresses shows that he is doing a private act. Since it is a private act, we don't want to know that he distributed 10 addresses to this customer and therefore, the allotment of 10 addresses does not need to be registered in the RIPE database. If he had given out an entire /64 to the customer we still don't need to see this apportionment in the database. The addresses designated for a customer only need to be seen in the database when the act of earmarking these addresses for customer use is in alignment with the RIPE policy. Presumably, at a technical level, if there is no route created in the service provider's OSPF or ISIS then it doesn't need to be published. But don't take my word for that because I really don't understand what RPE-267 3.3 says. > The policy is a bit vague here, admitted. I agree. --Michael Dillon From jeroen at unfix.org Thu Oct 6 13:57:52 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 06 Oct 2005 13:57:52 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: References: Message-ID: <1128599872.7912.24.camel@firenze.zurich.ibm.com> On Thu, 2005-10-06 at 11:44 +0100, Michael.Dillon at btradianz.com wrote: > > The answer is "the RIPE policies have no answers how to do things that > > are in violation of the RIPE policies" - and assigning 10 IPv6 addresses > > > is against the policy. > > Assigning 10 IPv6 addresses is *NOT* against RIPE policy! Not in text, but as an ISP, per the policy, you say that you are going to assign /48's to endsites. If one is only going to give out single IP's then you are an endsite, thus you are only supposed to be getting a /48 in the first place. > It may come as a surprise to those of you who do not speak > English as a native language, but the word "assign" is a > synonym of the word "allocate" and both have a very general > meaning of distributing something to multiple recipients. > The fact that RIR policies use these synonyms in specific and > distinct ways does not change the fact that anyone who learns > English as a language of communication will learn that these > two words mean the same thing and can be substituted for one > another. When I allocate 10km^2 of land for a building project I still do not assign that 10km^2 of land to anybody. It's allocated, thus waiting to be assigned. Also I am quite sure that when I mention "IP" here that people will read this as "Internet Protocol", most likely not evening thinking of the long version, and not as "IPR", while lawyers read IP as "Intellectual Propery" and don't even know the term IPR which engineers know stands for "Intellectual Property Rights". All is english, still doesn't mean the same thing. Context does matter. Then again, I am not a native english speaker and I don't grab a copy of Websters for every word, but it is still how I and I guess many others, read them. It also has to do mostly with the familiarity of process. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: From gert at space.net Thu Oct 6 14:00:06 2005 From: gert at space.net (Gert Doering) Date: Thu, 6 Oct 2005 14:00:06 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: References: Message-ID: <20051006120006.GC5931@Space.Net> Hi, On Thu, Oct 06, 2005 at 11:42:28AM +0100, Michael.Dillon at btradianz.com wrote: > The technology specifies that a "network" should be assigned > a /64 but this thing called a "network" may not be an > Ethernet broadcast domain. Different people will do different > things with devices and this will lead them to use different > address allocation strategies. For instance, consider an > RS-232 cable daisychained through a factory with modems to > handle the signal strength amplification when the signal > gets too strong. Imagine 10 devices attached to this daisy > chained RS 232 cable which use IPv6 to communicate. One > might consider this a network or one might not. > > Is this decision a public policy decision or not? No, as this is not related to policy. But if the owner of that network comes and asks for addresses, the policy has a very clear answer: he will not get "10" addresses, but at least a /64. If the daisy chain is organized in a way that more than one broadcast segment makes technical sense, he will get more than a /64. (And *this* discussion is precisely about the question how much "more than a /64" is - a /56 or a /48). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Thu Oct 6 14:08:56 2005 From: gert at space.net (Gert Doering) Date: Thu, 6 Oct 2005 14:08:56 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: References: Message-ID: <20051006120856.GD5931@Space.Net> Hi, On Thu, Oct 06, 2005 at 11:44:32AM +0100, Michael.Dillon at btradianz.com wrote: > > The answer is "the RIPE policies have no answers how to do things that > > are in violation of the RIPE policies" - and assigning 10 IPv6 addresses > > > is against the policy. > > Assigning 10 IPv6 addresses is *NOT* against RIPE policy! Please read the policy documents. There is no provisioning for assignment of > It may come as a surprise to those of you who do not speak > English as a native language, but the word "assign" is a > synonym of the word "allocate" and both have a very general > meaning of distributing something to multiple recipients. > The fact that RIR policies use these synonyms in specific and > distinct ways does not change the fact that anyone who learns > English as a language of communication will learn that these > two words mean the same thing and can be substituted for one > another. It may come as a surprise to you, but it's not so unsual to assign very specific meanings to certain terms when being used in certain professional environments. The most important point is to define exactly what the word specifies, and follow the official definitions *of this profession* when discussing details. You can't go to a lawyer either and argue about the fact that some generic terms have different meanings in a lawmaking context. That's the way language works. > Even worse (Horrors!) these two words can be used in business > outside of the context of the RIRs. ISPs can allocate circuit > bandwidth to customers, assign them to router ports, distribute > IP addresses to them, etc. Which has nothing to do whatsoever with the specific and precisely defined words "assignment" an "allocation" in the context IP address distribution. > Inside the business he can certainly assign 10 addresses to > his customer, however the very fact that he is choosing to > allocate the customer 10 addresses shows that he is doing > a private act. Please re-read the policy documents. The IP address distribution policies very specifically specify the rules how address distribution to 3rd parties are to be done, and every LIR signs a document that states "yes, we will follow all agreed-upon policies and procedures". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From mohacsi at niif.hu Mon Oct 10 13:02:45 2005 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 10 Oct 2005 13:02:45 +0200 (CEST) Subject: [address-policy-wg] IPv6 micro allocation or something else? Message-ID: <20051010124501.S40670@mignon.ki.iif.hu> Dear All, I have a question regarding the IPv6 address assignment to cc level DNS server. If you don't have answer to this question please forward it to an appropriate working group - sorry for cross-posting this mail to two wg. We have here in Hungary a dilemma: - Traditionally, the IPv4 address of the primary cc level DNS server in of belonged to NIIF/HUNGARNET. - The DNS registration service a while ago was delegated to Council of Hungarian Internet Providers (ISZT) who is also operating the biggest Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including NIIF/HUNGARNET) has right to do the registration via a special interface. - The IPv4 address of the primary cc level DNS server announced by NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate address from a new PI type IPv4 address space to DNS servers. - The primary hu DNS server is connected to BIX - to be well connected. What IPv6 address space should we allocate to hu primary DNS server? 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? - not very optimal since the only transit to hu primary will be NIIF/HUNGARNET - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and ripe-310)? - According to the RIPE documents: "Networks assigned under this policy may not be globally routable" - which problematical since primary DNS servers should be globally reachable. 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS server? - This can be problematical since the answers to DNS queries might be quite big. 4. Allocate /48 to primary hu DNS server that is globally routable? Are there similar to /48 from 2001:0500::/30 in RIPE region? - I think this is the cleanest solution. Can we discuss this issue on the working group or mailing lists? I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html In my opinion this can solve the problem.... Best Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 From woeber at cc.univie.ac.at Mon Oct 10 15:22:46 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 10 Oct 2005 14:22:46 +0100 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <4343E2CF.4080307@ripe.net> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> <4343E2CF.4080307@ripe.net> Message-ID: <434A6B26.2080604@cc.univie.ac.at> Denis Walker wrote: > leo vegoda wrote: > > >>On Oct 5, 2005, at 2:28 pm, J?rgen Hovland wrote: >> >>[...] >> >> >>>I apologise if this is moot, but an answer would really be appreciated. >>>This becomes a problem with private users as it already is today. We >>>can't store data about every single private user into a public >>>database, and there might also be issues regarding the privacy act. >>>It breaks the "true spirit of IPv6"; "have enough addresses, and no >>>questions asked". >> >> > Can I ask a different question here? I have only seen the RIPE Whois > Database from the RIPE NCC side. I have never worked for an ISP/LIR so I > am not sure how you use all of the data contained in the Database. > > Does anyone actually use the addresses and phone numbers from person > objects? Or is all communication done these days by e-mail? As long as email is working, we prefer it over using phone:-) What we have seen over time is that smaller customers do some sort of channel hopping with their domain/mail and/or web services, and often forget to update the registry data. Then we try the phone, and the fax. Wilfried. From webmaster at ripe.net Thu Oct 13 14:35:23 2005 From: webmaster at ripe.net (RIPE NCC Document Announcement Service) Date: Thu, 13 Oct 2005 14:35:23 +0200 Subject: [address-policy-wg] New RIPE Document available: RIPE-353 Message-ID: <200510131235.j9DCZNgL016470@birch.ripe.net> New RIPE Document Announcement -------------------------------------- A new RIPE Document is available from the RIPE Document store. Ref: ripe-353 Title: ASN Missing In Action, A Comparison of RIR Statistics and RIS Reality Author: Henk Uijterwaal, Rene Wilhelm Date: October 2005 Format: PDF=763999 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- In this paper, we look at Autonomous System Number (ASN) assignments by the Regional Internet Registries (RIRs) and the number of unique ASNs seen by routers on the Internet. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/ripe-353.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-353.pdf PDF version Kind Regards, RIPE NCC Document Announcement Service From mohacsi at niif.hu Fri Oct 14 12:32:54 2005 From: mohacsi at niif.hu (Mohacsi Janos) Date: Fri, 14 Oct 2005 12:32:54 +0200 (CEST) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051010124501.S40670@mignon.ki.iif.hu> References: <20051010124501.S40670@mignon.ki.iif.hu> Message-ID: <20051014122508.G77157@mignon.ki.iif.hu> Dear All, I did not see any answers except one from Bill Manning - who was supporting the 4. options. So this means this is the accepted and RIPE reccomended method. Basically allow allocating portable IPv6 address: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; When the RIPE policy will reflect this changes? Thanks Regards, Janos Mohacsi Network Engineer, Research Associate NIIF/HUNGARNET, HUNGARY Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 On Mon, 10 Oct 2005, Mohacsi Janos wrote: > Dear All, > I have a question regarding the IPv6 address assignment to > cc level DNS server. > > If you don't have answer to this question please forward it to an appropriate > working group - sorry for cross-posting this mail to two wg. > > We have here in Hungary a dilemma: > > - Traditionally, the IPv4 address of the primary cc level DNS server in of > belonged to NIIF/HUNGARNET. > > - The DNS registration service a while ago was delegated to Council of > Hungarian Internet Providers (ISZT) who is also operating the biggest > Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including > NIIF/HUNGARNET) has right to do the registration via a special interface. > > - The IPv4 address of the primary cc level DNS server announced by > NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate > address from a new PI type IPv4 address space to DNS servers. > > - The primary hu DNS server is connected to BIX - to be well connected. > > > What IPv6 address space should we allocate to hu primary DNS server? > > 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? > - not very optimal since the only transit to hu primary will be > NIIF/HUNGARNET > - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET > > > 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 and > ripe-310)? > - According to the RIPE documents: "Networks assigned under this policy may > not be globally routable" - which problematical since primary DNS servers > should be globally reachable. > > 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS > server? > - This can be problematical since the answers to DNS queries might be quite > big. > > 4. Allocate /48 to primary hu DNS server that is globally routable? > Are there similar to /48 from 2001:0500::/30 in RIPE region? > > - I think this is the cleanest solution. > > Can we discuss this issue on the working group or mailing lists? > > I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html > > In my opinion this can solve the problem.... > > Best Regards, > > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > From fw at deneb.enyo.de Mon Oct 17 20:05:35 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 17 Oct 2005 20:05:35 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <4343E2CF.4080307@ripe.net> (Denis Walker's message of "Wed, 05 Oct 2005 16:27:27 +0200") References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <00a701c5c9a8$428183c0$c0dea8c0@hipercom.local> <4343E2CF.4080307@ripe.net> Message-ID: <87k6gct3ww.fsf@mid.deneb.enyo.de> * Denis Walker: > Does anyone actually use the addresses and phone numbers from person > objects? Or is all communication done these days by e-mail? The email address is still optional, IIRC. I occasionally use phone numbers, but only very rarely or in ways that have nothing to do with networking (e.g. misusing the RIPE database as a phonebook). From fw at deneb.enyo.de Mon Oct 17 20:10:15 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 17 Oct 2005 20:10:15 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <20051005113123.GS5931@Space.Net> (Gert Doering's message of "Wed, 5 Oct 2005 13:31:23 +0200") References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> Message-ID: <87fyr0t3p4.fsf@mid.deneb.enyo.de> * Gert Doering: > There is no option to give "10 addresses" to a user - period. What about transfer networks? How do you handle those? From gert at space.net Fri Oct 21 18:22:35 2005 From: gert at space.net (Gert Doering) Date: Fri, 21 Oct 2005 18:22:35 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <87fyr0t3p4.fsf@mid.deneb.enyo.de> References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> Message-ID: <20051021162235.GS65405@Space.Net> Hi, On Mon, Oct 17, 2005 at 08:10:15PM +0200, Florian Weimer wrote: > > There is no option to give "10 addresses" to a user - period. > What about transfer networks? How do you handle those? The RFC says "all networks get a /64" (unless running unnumbered). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fw at deneb.enyo.de Fri Oct 28 00:51:38 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 28 Oct 2005 00:51:38 +0200 Subject: [address-policy-wg] 2005-08 New Policy Proposal In-Reply-To: <20051021162235.GS65405@Space.Net> (Gert Doering's message of "Fri, 21 Oct 2005 18:22:35 +0200") References: <20051005084715.GN5931@Space.Net> <200510051004.j95A4K3R027248@mail03.hipercom.no> <20051005103217.GR5931@Space.Net> <007701c5c99d$79b683a0$c0dea8c0@hipercom.local> <20051005113123.GS5931@Space.Net> <87fyr0t3p4.fsf@mid.deneb.enyo.de> <20051021162235.GS65405@Space.Net> Message-ID: <87mzkuy3np.fsf@mid.deneb.enyo.de> * Gert Doering: > On Mon, Oct 17, 2005 at 08:10:15PM +0200, Florian Weimer wrote: >> > There is no option to give "10 addresses" to a user - period. >> What about transfer networks? How do you handle those? > > The RFC says "all networks get a /64" (unless running unnumbered). I'm not concerned with the network, but with the IP addresses which are given to routers. Or are you expected to run autoconfiguration on transfer networks? From echatzifotiou at telepassport.gr Mon Oct 31 09:47:28 2005 From: echatzifotiou at telepassport.gr (Eri Chatzifotiou) Date: Mon, 31 Oct 2005 10:47:28 +0200 Subject: [address-policy-wg] (no subject) Message-ID: <012101c5ddf7$bacffa60$6a62c552@open.net> We are gr.tpp We have a point of presence, which is in Cyprus (Different Country) and for now, we are using a /24 Subnet for their needs. The problem is that they need to anounce this subnet through a different isp then the one that we are using. They want only to anounce the 82.197.100.0 /255 to their isp cooperator. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: