This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2005-08 New Policy Proposal
- Previous message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
- Next message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Wed Oct 5 12:32:17 CEST 2005
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
- Previous message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
- Next message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]