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 <address-policy-wg@ripe.net> 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
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@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of RIPE NCC Policy Coordinator Sent: 5. oktober 2005 10:03 To: policy-announce@ripe.net Cc: Kurtis Lindqvist; Hans Petter Holen; address-policy-wg@ripe.net; gih@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 <address-policy-wg@ripe.net> 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
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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@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 isnt 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 didnt 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
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 isnt 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 didnt 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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
----- Original Message ----- From: "Gert Doering" <gert@space.net> 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
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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
----- Original Message ----- From: "Gert Doering" <gert@space.net>
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
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
----- Original Message ----- From: "leo vegoda" <leo@ripe.net>
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
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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
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,
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
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)
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?
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.
* 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).
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@...", 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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
----- Original Message ----- From: "Gert Doering" <gert@space.net> To: "Jørgen Hovland" <jorgen@hovland.cx> Cc: "Gert Doering" <gert@space.net>; <address-policy-wg@ripe.net> 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@...", 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
* Gert Doering:
There is no option to give "10 addresses" to a user - period.
What about transfer networks? How do you handle those?
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@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
* 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?
Hi, On Fri, Oct 28, 2005 at 12:51:38AM +0200, Florian Weimer wrote:
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?
Indeed, this is an interesting issue, and each ISP will find his own way to handle this. Currently, we tend to use the "<prefix>::1" on our side of all links, and the customer can use whatever he likes - which is usually ::2. Autoconfiguration for routers works, but is not overly helpful, as the other router on the network needs to know the router's IP to route packets in its direction... - unless you run OSPFv3 (or ISIS), in which case IPv6 autoconfig (or "just use link-locals") would actually work fine. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
----- Original Message ----- From: "Gert Doering" <gert@space.net>
Hi,
On Fri, Oct 28, 2005 at 12:51:38AM +0200, Florian Weimer wrote:
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?
Indeed, this is an interesting issue, and each ISP will find his own way to handle this.
Currently, we tend to use the "<prefix>::1" on our side of all links, and the customer can use whatever he likes - which is usually ::2.
Autoconfiguration for routers works, but is not overly helpful, as the other router on the network needs to know the router's IP to route packets in its direction... - unless you run OSPFv3 (or ISIS), in which case IPv6 autoconfig (or "just use link-locals") would actually work fine.
Hi,
From the input I received I got the impression that you have to assign a /64 no matter what. So it means you use 2 IPs (or 10 in my case) and toss the other 2 - 2^64 away and then continue with next customer and assign a new /64 and so on. I hope I see the point of all this address waste in a few years. In the mean time I'll just do it(tm).
Cheers, Joergen Hovland
Hi, On Wed, Nov 02, 2005 at 07:24:02PM +0100, Jørgen Hovland wrote:
From the input I received I got the impression that you have to assign a /64 no matter what.
Yes, and there are good reasons for that. (Personally, I disagree with the choice of a /64 for "any sort of network segments", but there *are* good reasons, and this is more an IETF engineering decision than a RIPE address policy thing)
So it means you use 2 IPs (or 10 in my case) and toss the other 2 - 2^64 away and then continue with next customer and assign a new /64 and so on. I hope I see the point of all this address waste in a few years. In the mean time I'll just do it(tm).
I hope you'll learn a little bit of math in the next few years - there are enough /64s. Whatever you want to do with it. And no, the standard argument "and everybody said 640K was enough" does *not* hold. Just do the math. (Inside a single /32, there are 4 *billion* /64s. How many customers did you say that you're going to connect to your network?) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
I hope you'll learn a little bit of math in the next few years - there are enough /64s. Whatever you want to do with it.
some of us are old enough to remember when we thought that about 32 bits of address. i really wish i could find the famous quote that said (about computer memory addressing, i believe) that, no matter what size you choose, it will be too small sooner than you planned. randy
Hi, On Wed, Nov 02, 2005 at 12:20:47PM -1000, Randy Bush wrote:
I hope you'll learn a little bit of math in the next few years - there are enough /64s. Whatever you want to do with it.
some of us are old enough to remember when we thought that about 32 bits of address.
Now *this* part of math is easy. "Less IPs than people around are not going to make everybody happy". Yes, IPv6 could eventually be too small, if you end up ging every single RFID chip its own /64 - but nobody is proposing that. If you give every "reasonable" subnet a /64, I find it hard to envision a way to connect 4 billion subnets to a single (and small!) ISP.
i really wish i could find the famous quote that said (about computer memory addressing, i believe) that, no matter what size you choose, it will be too small sooner than you planned.
So what's your suggestion? Turn off the Internet, and go fishing? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
i really wish i could find the famous quote that said (about computer memory addressing, i believe) that, no matter what size you choose, it will be too small sooner than you planned. So what's your suggestion? Turn off the Internet, and go fishing?
no, snorkeling. eat your heart out, cold weather boy! don't be silly. given the stupid political decision not to use variable length addressing, we need to be reasonably prudent. for p2p links, many of us use /126s. assign the customer the space they actually need. throw in one extra bit for insurance, two if you feel profligate. but not a /48. discuss getting rid of the /64 silliness. remember tlas? at least they're gone. yes, this is the "ipv4 mindset." but, after all, the v6 so-called architects only gave us ipv4 second system syndrome, no scalable routing, no extensible addressing, no loc/id sep, ... we've gone from a limit of 640k of ram to 1gb. big whoopiedoo. in ten years, we'll wish that was 1tb. randy
Jørgen Hovland wrote:
From the input I received I got the impression that you have to assign a /64 no matter what. So it means you use 2 IPs (or 10 in my case) and toss the other 2 - 2^64 away and then continue with next customer and assign a new /64 and so on. I hope I see the point of all this address waste in a few years. In the mean time I'll just do it(tm).
Hi, *long time listener, first time speaking up'er* I share the views of Mr. Hovland, using a /64 for networks that only requires a few addresses seems like such a waste. Personally, I use /126 for p2p links. And, I see the point in 'we have more addresses than there are people in this world'. I haven't done the math for it, but if we waste 18446744073709551614 addresses for every single customer, will this stick? Will we regret it sometime in the future? (or rather; will our grandchildren think we were stupid in the future?) <joke> Me and a guy from work had a laugh, and visioned ourselvs being old, and being interviewed by 'Discovery History' because we ran out of IPv6 addresses saying: "I remember I was a kid back then, but that's what I thought would happen..' </joke> -- Sincerely, Espen Holm Nilsen
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.
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.
participants (13)
-
Denis Walker -
Espen Holm Nilsen -
Florian Weimer -
Geoff Huston -
Gert Doering -
Hank Nussbacher -
Jørgen Hovland -
leo vegoda -
Pim van Pelt -
Randy Bush -
RIPE NCC Policy Coordinator -
Sander Steffann -
Wilfried Woeber, UniVie/ACOnet