[ale] IPv6 Subnetting
Michael H. Warfield
mhw at WittsEnd.com
Tue Feb 15 12:14:51 EST 2011
On Tue, 2011-02-15 at 00:16 -0500, Michael B. Trausch wrote:
> On Mon, 2011-02-14 at 21:28 -0500, David Tomaschik wrote:
> > I'm no networking expert, so I hope I'm missing something here.
> >
> > According to RFC 4291, all interface IDs for unicast addresses will be
> > 64 bits in length. It's also widely believed that most residential
> > ISPs will hand out a /64 on a per-client basis. Because IPv6 does not
> > have the concept of NAT, it seems that this forces all of the
> > computers on that connection to be on a single subnet.
> More or less. Though it isn't exactly as black-and-white as all that.
> There are options (albeit non-standard). It is (technically) possible to
> do things that are slightly more complicated, at the expense of not
> being able to use stateless autoconfiguration).
Don't go there if you can avoid it. We want to avoid IPv4 mind think
here.
If you need more than one subnet, you're suppose to get a larger
allocation and the ISP should make one available.
Per the standards...
If you need 1 subnet you get a /64. If you need more than one subnet,
you should get a /48 but some ISPs such as freenet6 may break that down
further and hand you a /56 which is still 256 subnets. Yes, most ISPs
should be handing you a /64 as a default. That is per the standard if
that's all you need and that will be the case with most residential
customers. If you need more, they should allocate you more or they are
in violation of the standards.
Mike
> > This is rather disappointing to me, as in the past I have run 3 NAT
> > subnets off a single NAT router/firewall. I've used one as my
> > "regular" LAN (workstations, one wifi SSID), a "guest" LAN (another
> > SSID with a different key for my guests) and a lab network (for
> > testing things I'd rather keep separate). It seems to me that under
> > IPv6 this addressing scheme will be impossible unless I can convince
> > my ISP to hand out a /56. (Or, I suppose, multiple /64s and have
> > multiple (virtual) interfaces on the router.)
That's no different than them handing out one IPv4 address now. You
should be able to request more and they should provide them to you on
request but you will have to request it. Some ISPs will give you
multiple IPv4 addresses on request (and payment) but it won't be the
default case in either case. They'll have a lot more IPv6 space to hand
out that they ever dreamed of with v4.
> It is possible to subnet further than /64, at least as I understand it.
> So, let's say you've got a /64 prefix 2001:db8:49a1:39be::/64.
Don't do it. Anything less that a /64 is suppose to be for special
purposes (peering and routing) and point to point links, NOT for
subnetting.
Mike
> Now, you want three subnetworks from that. You will need a router at
> your network's edge (a true router; not a NAT). And of course, if you
> desire firewalling, you'll want that at the edge of your network. The
> router is likely then to be connected to all three subnetworks, and to
> the Internet. (At least, that's how I would likely do it, unless you
> have a device like a WRT54G that will perform routing, but you'll need
> to configure that specially for that purpose).
>
> Now, then, you can subnet two ways: take a nybble for the subnetwork, or
> take a byte. If you have 3 subnets, and you don't think you'll ever go
> above 16 subnets, take a nibble. That means your prefix that you'll
> actually use will be one of sixteen different /68 subnetworks inside
> your /64. (For that matter, you can take just two bits, and have
> exactly three subnetworks. Up to you---but either way, you break
> stateless autoconf, so might as well do four or eight bits and move on.)
> If you take a nybble, then you will have the following subnetworks
> available to use:
>
> 2001:db8:49a1:39be:0000::/68 2001:db8:49a1:39be:8000::/68
> 2001:db8:49a1:39be:1000::/68 2001:db8:49a1:39be:9000::/68
> 2001:db8:49a1:39be:2000::/68 2001:db8:49a1:39be:a000::/68
> 2001:db8:49a1:39be:3000::/68 2001:db8:49a1:39be:b000::/68
> 2001:db8:49a1:39be:4000::/68 2001:db8:49a1:39be:c000::/68
> 2001:db8:49a1:39be:5000::/68 2001:db8:49a1:39be:d000::/68
> 2001:db8:49a1:39be:6000::/68 2001:db8:49a1:39be:e000::/68
> 2001:db8:49a1:39be:7000::/68 2001:db8:49a1:39be:f000::/68
>
> The three zeros you see in each address there is, of course, part of the
> host section, since each hex digit maps exactly to one nybble.
>
> If you use a /72 then you would have 256 subnetworks. Either way, you
> need to use static addresses, stateless algorithmic address generation
> (e.g., custom software to create shorter addresses in a stateless
> manner), or DHCPv6.
>
> Your nodes will still make their link-local addresses the same way. And
> as far as your ISP is concerned, you're using your /64. The details of
> your routing behind that /64 do not matter to them: your address space
> is perfectly opaque as far as they're concerned.
>
> You could actually, if you really wanted to, make subnetwork prefixes as
> long as /112 or /120 or /126 if you wanted really small networks. I
> mean, crap. You've got 64 bits of network space to carve up and do with
> what you wish. :-)
>
> Now, that said, here is a BIG DISCLAIMER: I have never *actually*
> performed this. I believe that Linux allows it; based on my
> understanding, any standards-compliant operating system should. YMMV.
>
> --- Mike
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110215/d06bf4d5/attachment.bin
More information about the Ale
mailing list