|
PTP Tunnel is a huge /64
![[de]](/s/countries/de.gif) Shadow Hawkins on Monday, 27 July 2009 01:53:39
Hi,
since it seems impossible to make use of any address besides $foo::2 on a /64 "subnet" tunnel, why are such large subnets handed out at all? Should not it be something like /128 (or 127), since it is just a pointtopoint link?
PTP Tunnel is a huge /64
![[si]](/s/countries/si.gif) Shadow Hawkins on Monday, 27 July 2009 11:17:50
That is not a real subnet. If you want a subnet, you must request it separately.
It is all explained in the docs and FAQ...
PTP Tunnel is a huge /64
since it seems impossible to make use of any address besides $foo::2 on a /64 "subnet" tunnel, why are such large subnets handed out at all?
$tunnel::1 == PoP
$tunnel::2 == user
The /64 is a transport network. Now it is a tunnel, maybe one day it will become a multi-point tunnel, where ::3 is another PoP, or we start using CGA, or the link is actually natively done over Ethernet. Also, Multicast is a lot happier this way.
Should not it be something like /128 (or 127), since it is just a pointtopoint link?
/128 is definitely too small as it is only 1 IP address, /127 is only two IP addresses, but there is this thing called a 'subnet anycast address', which is always the lowest IP in a prefix, as such if you use $tunnel::/127, $tunnel::0 is the subnet anycast address, and then you only have $tunnel::1 left, again not enough.
This is why that does not work, and why guess there is enough space and the standards define it this way.
Also, per PoP we currently have a single /48, cut up in 65536 /64's. If we would go for a /127, we would have to use a /64 (out of a /48) and there would be 2^(127-64)) ehmmm, well way too many of them. There is no disadvantage in this setup, except maybe in the brain.
PTP Tunnel is a huge /64
Shadow Hawkins on Monday, 27 July 2009 14:01:29/128 is definitely too small as it is only 1 IP address
For IPv4, /32 would also be "too small", yet is not. PTP links are commonly assigned a single IPv4 address (e.g. T-DSL), for example, `ip addr add 217.2.3.4/32 peer 217.1.1.1`. Is this perhaps different for IPv6? If one does not want/need any- or multicast, doing a similar host route for IPv6 would not seem that far-fetched.
per PoP we currently have a single /48 [...] If we would go for a /127, we would have to use a /64 [...] and there would be 2^(127-64)) ehmmm
But would it be a problem? Whether other BGPs have an entry 2a01:198:200::/48 or 2a01:198:200::/64 does not seem to make a difference - it is still just one route in their tables. Yes, there would be that-many possible /127 nets, but that does not mean there have to be so-many actual routes (just as many as there are assigned to users). Or did I go wrong somewhere in the thought process?
PTP Tunnel is a huge /64
Shadow Hawkins on Monday, 27 July 2009 14:21:18
See: RFC3627 - Use of /127 Prefix Length Between Routers Considered Harmful
basically, the largest prefix in IPv6 is /64 .. period..
PTP Tunnel is a huge /64
Is this perhaps different for IPv6?
IPv4 != IPv6, it mostly is, but in many cases it isn't. What you should also realize is that for "A" it might work, but if you then want to do "B" it doesn't. Designing a network to be able to do A, and later maybe B is a smart move. And why bother with limiting yourself, when it doesn't matter anyway.
But would it be a problem? Whether other BGPs have an entry 2a01:198:200::/48 or 2a01:198:200::/64 does not seem to make a difference - it is still just one route in their tables. Yes, there would be that-many possible /127 nets, but that does not mean there have to be so-many actual routes (just as many as there are assigned to users). Or did I go wrong somewhere in the thought process?
Yes, the part that there will never be an umptillion /127s and thus why bother with it while it will break various design and usage possibilities as it only fits very few scenarios.
Those /127's still need to come out of something. As everything gets split up into /48s and then into smaller portions, one is still using a /48 for those /127s. Thus as 65k /64s is definitely way more than enough per PoP, we use a /64 there, which is the same as would be used for Ethernet links etc. It makes everything 'the same', nothing magic to think about etc and it allows for all kinds of future things, if we ever do them.
PTP Tunnel is a huge /64
![[us]](/s/countries/us.gif) Shadow Hawkins on Tuesday, 03 November 2009 20:23:31
I think I see where he's coming from; he's likely not used to having to create addresses for adapters *manually*, which Vista and Windows 7 both force him to do. In my case, while I don't exactly consider it *fun*, I developed a system for manually-created sub-addresses from my /64:
The address-creation system revolves around the fifth four-place group (an IPv6 address consists of eight four-place groups, with digits from 0-f; the first four groups are assigned by SixxS and are thus unusable - the user-assignable portion starts with the fifth group and runs from 0000:0000:0000:0003 to ffff:ffff:ffff:fffd)
Because I don't have a router handing the addresses out (and most won't at least at first), for Windows, the system as I employ it is as follows:
(0002:xxxx:xxxx:xxxx - physical adapters)
(0003:xxxx:xxxx:xxxx - Sun VirtualBox non-host adapters)
(0004:xxxx:xxxx:xxxx - VMWare virtual non-host-only adapters)
(0005:xxxx:xxxx:xxxx - Parallels virtual non-host adapters)
No group can run out of room, and every possible adapter option will fit a group. Wireless Ethernet, for example, is in the physical adapters group, while VMware's VMnet8 adapter is in the VMware non-host adapters' group. It even leaves space for other sorts of virtual adapters that may want/need IPv6 connectivity (smartphones, for example, could be placed at 0006:xxxx:xxxx:xxxx); even beter, unlike IPv4, leading zeros are dropped even at creation time, so you need not type out the entire chain. (A second Ethernet adapter, wired or wireless, would have a manually-created address, for example, of 2003:4870:1840:33f:2:0:0:2, assuming that the user's tunnel is 2003:4870:1840:33f::/64.)
That's merely one example - you can divvy up those subaddresses any way that suits you.
PTP Tunnel is a huge /64
The address-creation system revolves around the fifth four-place group (an IPv6 address consists of eight four-place groups, with digits from 0-f; the first four groups are assigned by SixxS and are thus unusable - the user-assignable portion starts with the fifth group and runs from 0000:0000:0000:0003 to ffff:ffff:ffff:fffd)
Ehmmm, that is quite wrong. There is a tunnel prefix, which is a /64. Of this <tunnel>::1 is the PoP, <tunnel>::2 is the endpoint of the user. The rest of that address space is unused.
Now, if you get a subnet, which is a /48, you get that fully routed to <tunnel>::2. The whole /48, thus 2^(128-48-64 = 16) = 65536 /64's in that /48 are fully available to put anywhere you want.
for example, of 2003:4870:1840:33f:2:0:0:2,
2001:db8::/32 is the example/documentation address space.
But why are you bothering with the last 64 bits? Just use a /64 per VM-type and route it appropriately to the right adapter and use autoconfig to do the rest. Simple.
PTP Tunnel is a huge /64
Shadow Hawkins on Wednesday, 04 November 2009 14:36:52
Simple; Windows 7 (or Vista, or even XP) doesn't allow autoconfiguration on the client; if it did, I wouldn't be going through such silliness. Also, by sticking strictly to the last 64 bits and the fist *usable* 64 bits, it keeps the system understandable by humans.
The /64 calculation system I used is based on the tunnel prefix; as you pointed out, ::1 and ::2 are the endpoints, and thus reserved. However, even in a /64,
there are far more addresses than any single person (in fact, any single *business*) could use. With my system, the second and third 64-bit groups in any address inn the system will always be zero. (An alternate could instead use the next to last and last 64-bits for address-creation, keeping the first two 64-bits at zero.) Either way would work, and neither would be under any address pressure.
It also illustrates quite nicely the utter lack of usefulness of NAT in an IPv6 space for any reason other than security.
PTP Tunnel is a huge /64
Shadow Hawkins on Wednesday, 04 November 2009 14:46:33 Simple; Windows 7 (or Vista, or even XP) doesn't allow autoconfiguration on the client; if it did, I wouldn't be going through such silliness.
Not true. RADVD works great. I'm advertising prefixes on 5 separate subnets without any problems. All of my Mac, Linux, Unix, and Windows hosts receive an address when they boot into their respective operating systems
PTP Tunnel is a huge /64
Except for <tunnel>::1 and <tunnel>::2 in the tunnel /64, everything else is unused & unusuable as it is unrouted. Doing anything with it does not work (except for your local routes that you setup).
The big question then is how you configured this, and most likely that leads to the answer to the reason why your autoconfig does not work.
To give you a hint: you can only use a /64 on one link, not multiple and autoconfig only works with /64 prefixes.
And for IPv6 there is no "address pressure", this as there are 2^128 addresses or actually more 2^(128-48) sites with each 2^(128-48-64)=65536x /64.
If you can devise a scheme where that will run out, good luck.
It also illustrates quite nicely the utter lack of usefulness of NAT in an IPv6 space for any reason other than security.
Ehmmmmmm I think you have to start understanding that the only 'security' in NAT is the connection tracking portion, and that that actually doesn't give you any "security" whatsoever.
Might I suggest you read a book about IPv6 and realize that IPv6 is far from IPv4, even though it kinda looks like it?
PTP Tunnel is a huge /64
Shadow Hawkins on Saturday, 21 November 2009 14:55:10
Windows 7, Windows Vista and Windows XP all allow autoconfiguration of the client. Windows XP however, does not support DHCPv6. The other two probably should.
As for your way of segmenting the tunnel /64 address space, there are two things to consider here:
1. The /64 address space you are discussing here - the one which is used to address the two sides of the tunnel, and the one for which most think that it wastes 2^64-2 addresses - is not yours. This is used purely to number the transit link to your site. If you do not have a subnet assigned, well, you're just exploiting the tunnel endpoint to reach the ipv6 internet. If you want to have more than one (1) address available, ask for a subnet. Even in ipv4 world, if you have PI, your uplinks will be numbered using provider addresses and while you MAY use those as source addresses to reach the internet you will not do it.
2. It is unnecessary to be sentimental about 2^64-2 addresses. Unless you want to make your life more complicated, you will use /64 on all links. Okay, for your own private transit PtP links you may use link local addresses. Otherwise you should just stick with public and /64. Originally, SIPP (which became IPv6 later) was designed with 64 bit address space. This was increased to 128 bits precisely because of stateless autoconfiguration, if I got my history right. So, instead of thinking "Oh my, we just wasted 2^64 addresses ...", start thinking "Hey, great, I just got 2^64 extra addresses on this segment!".
And if you're still skeptical, consider the fact, that we still havent run out of 48 bit MAC addresses, which are used for every single ethernet interface in the world and, with many vendors, for every port on every ethernet switch.
Just my 0.02 EUR to lessen the drama.
|
![[ch]](/s/countries/ch.gif)
on Monday, 27 July 2009 12:38:59
Posting is only allowed when you are