On Sun, 2011-02-27 at 00:38 -0600, Larry Vaden wrote:
On Sat, Feb 26, 2011 at 2:12 PM, Always Learning centos@g7.u22.net wrote:
Today I received an allocation of IP6 addresses for some servers. I can 'play' with the last 2 of the 8 IP6 address segments.
I guess Will Rogers was correct after all :)
You can label yourself as "special" since others get assignments of IPv4 and IPv6 addresses.
https://www.arin.net/policy/archive/ipv6_policy.html#25 says, in part:
2.5. Allocate
To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them.
2.6. Assign
To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties.
I was actually wrong. I can 'play' with not 2 but 4 groups of the IP6 allocation. Golly, what can I do with 64 x 64 x 64 x 64 address combinations? Hire then out? Have a different IP6 address for every hour of the year? Put the IP4 address in the last 4 groups? (2001::10.2.2.191)
That vast surplus of IP6 addresses is just for one server - I have several.
On Sun, Feb 27, 2011 at 3:44 PM, Always Learning centos@g7.u22.net wrote:
I was actually wrong. I can 'play' with not 2 but 4 groups of the IP6 allocation. Golly, what can I do with 64 x 64 x 64 x 64 address combinations? Hire then out? Have a different IP6 address for every hour of the year? Put the IP4 address in the last 4 groups? (2001::10.2.2.191)
That vast surplus of IP6 addresses is just for one server - I have several.
--
Assign a new IP to every service, every port and every instance of every service you can ever think of running ;)
On 2/27/11 8:00 AM, Rudi Ahlers wrote:
On Sun, Feb 27, 2011 at 3:44 PM, Always Learningcentos@g7.u22.net wrote:
I was actually wrong. I can 'play' with not 2 but 4 groups of the IP6 allocation. Golly, what can I do with 64 x 64 x 64 x 64 address combinations? Hire then out? Have a different IP6 address for every hour of the year? Put the IP4 address in the last 4 groups? (2001::10.2.2.191)
That vast surplus of IP6 addresses is just for one server - I have several.
--
Assign a new IP to every service, every port and every instance of every service you can ever think of running ;)
Just keep in mind that you'll have to remember them all to configure your firewalling appropriately - which will be painful if you don't arrange some sort of sensible ranges.
On Sun, Feb 27, 2011 at 01:44:17PM +0000, Always Learning wrote:
I was actually wrong. I can 'play' with not 2 but 4 groups of the IP6 allocation. Golly, what can I do with 64 x 64 x 64 x 64 address
That's an odd combination. "64" is 6 bits, which has nothing to do with an IPv6 group.
Many IPv6 allocations to end users are a /64, which means you get something like aaaa:bbbb:cccc:dddd:****:****:****:**** to play with; the a->d are fixed, you get the rest on your own.
That's actually 2^64 (or 65536*65536*65536*65536, or 18,446,744,073,709,551,616) addresses. IPv4 only has 2^32 addresses in total!
I have 2 /64s via tunnelbroker.net (one for home, one for my linode) and a native /80 from Panix for my v-colo.
Organisations may actually get /48 networks, just in case they're gonna run out. Actually it's if they want to subnet and route; a /64 is the best smallest subnet in many cases because of address autoconfiguration, so a /48 allows them to build 2^16=65536 subnets.
combinations? Hire then out? Have a different IP6 address for every hour of the year? Put the IP4 address in the last 4 groups? (2001::10.2.2.191)
Well, you won't have 2001:0:0:0:0:0, but there are mechanisms for this actually :-)
2001::10.2.2.191 is a perfectly valid way of writing 2001::0a02:02bf and is designed to help with the transition.
On 27/02/11 14:44, Always Learning wrote:
I was actually wrong. I can 'play' with not 2 but 4 groups of the IP6 allocation. Golly, what can I do with 64 x 64 x 64 x 64 address combinations? Hire then out? Have a different IP6 address for every hour of the year?
If you got allocated a /48 net from you ISP you will have this setup: <ISP prefix, 48 bit>:<16bit subnetting>:<64 bit address scope>
This gives you 65536 subnets with 64 bit subnet mask (/64). An example, 'AA' indicates the ISP, 'BB' indicates the subnet:
AAAA:AAAA:AAAA:BBBB::/64 ISP prefix 16 + 16 + 16 = 48 bits Your own subnets + 16 = 64 bits
If you are given a /56 net from you ISP, it will look more like this: <ISP prefix, 48 bit>:<cont. ISP prefix 8 bit><8 bit subnetting>:<64 bit addr>
This gives you 256 subnets with 64 bit subnet mask. An example:
AAAA:AAAA:AAAA:AABB::/64 ISP prefix 16 + 16 + 16 + 8 = 56 bits Your own subnets + 8 = 64 bits
It is really not recommended to segment your own networks in smaller subnets than /64 nets. F.ex. if you want to use radvd for stateless auto-configuration, it will expect 64 bit subnets. It is doable to make smaller subnets, but don't do that unless you really know what you're doing.
Using 64bit subnets makes it so easy to handle them. You know that the first 64bits of an address is the prefix to your own subnet. As there are no "network address" (like 192.168.0.0), no broadcast address (like 192.168.0.255), any addresses within a /64 subnet will be a valid IPv6 address for that subnet. And it will be a global IP address in addition.
The rest, is just firewalling and routing. Which is basically the same as in the IPv4 world, just with different address syntax.
Put the IP4 address in the last 4 groups? (2001::10.2.2.191)
I recommend you to *not* mix in stuff like this, at least in the very beginning. Run a dual stack IPv4 and IPv6 environment. It's easier to maintain, and they both run fine together in the same physical network segment.
That vast surplus of IP6 addresses is just for one server - I have several.
Yes, IPv6 gives every site a lot of more possibilities. And in IPv6 each NIC can have multiple IPv6 addresses, without using aliasing which is needed for IPv4. If you want to allocate 30 IPv6 addresses to one adapter, you may do so very easily. Just use 'ip -6 addr add <ipv6 addr> dev eth0'
kind regards,
David Sommerseth
On 2/27/11 9:38 AM, David Sommerseth wrote:
Yes, IPv6 gives every site a lot of more possibilities. And in IPv6 each NIC can have multiple IPv6 addresses, without using aliasing which is needed for IPv4. If you want to allocate 30 IPv6 addresses to one adapter, you may do so very easily. Just use 'ip -6 addr add<ipv6 addr> dev eth0'
Is there any difference in efficiency in how well the NIC hardware filters the assigned addresses? What about multicast - is there a good place to look for documentation?
On 2/27/11 12:50 PM, John R Pierce wrote:
On 02/27/11 9:16 AM, Les Mikesell wrote:
Is there any difference in efficiency in how well the NIC hardware filters the assigned addresses?
NIC's work in MAC addresses, not IP.
Sort-of. Most NICs know enough about IPv4 multicast to at least help filter unwanted addresses without bothering the CPU.
On 28/02/2011, at 10:30 AM, Les Mikesell wrote:
On 2/27/11 12:50 PM, John R Pierce wrote:
On 02/27/11 9:16 AM, Les Mikesell wrote:
Is there any difference in efficiency in how well the NIC hardware filters the assigned addresses?
Yes, as mentioned below, the NIC is given a list of Ethernet MAC addresses. Some [old, cheap] cards had a very small filter list [occassionally just a single entry], so the NIC would have to pass up pretty much any multicast so the next-layer (IP) could decide if it was wanted or not. This shouldn't be an issue today, unless you're using very old or very cheap cards.
NIC's work in MAC addresses, not IP.
Sort-of. Most NICs know enough about IPv4 multicast to at least help filter unwanted addresses without bothering the CPU.
Not quite. NICs have a list of Ethernet multicast MAC addresses that it can be assigned to pass on up the stack. These Ethernet multicast MAC addresses are determined from the IPv6 or IPv4 multicast address, but this is a kernel/driver issue, the NIC still does't have to know anything about IP.
Although, there certainly are NICs which know about higher-level protocols (TCP-offload engine), but that's a separate issue.
Ethernet _switches_, on the other hand, really need to know enough about IPv4/6 multicast in order to figure out which switch ports it should forward multicast traffic to (otherwise it floods, and we end up with the same traffic flow as broadcast). In IPv4, the switch needs to implement what is commonly called IGMP snooping. IGMP being the IPv4 protocol client devices use for subscribing to multicast groups. In IPv6, IGMP is instead part of ICMPv6 called Multicast Listener Discovery (typically version 2), and the switch feature to look for is called MLD[v2] snooping.
Hope this helps to clear up any misunderstanding. Cameron
-
Always Learning -
Cameron Kerr -
David Sommerseth -
John R Pierce -
Les Mikesell -
Rudi Ahlers -
Stephen Harris