Very interesting - ANDF (Architecture Neutral Distribution Format) was dreamt up during the Unix wars, by the OSF (who created a Unix clone called OSF/1, used only by Compaq Tru64 these days), and this compiler implements a format (TDF) that seems to be derived from this. The idea was that compilers would produce ANDF, an intermediate compiler output format, and vendors would then ship CDs containing ANDF 'binaries' - the customer installed on their Unix box, which could be Alpha, PA-RISC, x86, etc, and a special tool then did the last stage of compilation from ANDF to binary.
Not sure why this never took off, probably it was too much of a leap from existing technology and the Unix vendors saw it as commoditising their boxes. A few years later, Java's bytecode and use of JIT or install-time compilation came along and rendered this moot, though ANDF/TDF are probably still more flexible.
IPv6 will not solve this problem, which has nothing to do with NAT or load sharing. The key element of the solution is to provide a higher priority (CoS/QoS) for BGP traffic, and to somehow limit the amount of CPU spent on ARPing for non-existent IP addresses on the router's directly-connected subnets.
I am all for using IPv6 where appropriate, but it's irrelevant here. Putting in bigger pipes is expensive, and may well just make things worse (a Pentium III can just about saturate a gigabit ethernet link - what if some well-connected hosting centres get infected and start spamming the net via these larger pipes?).
Agreed, see http://slashdot.org/comments.pl?sid=22054&cid=2367 894 for some more info on this, in response to a post on out of band management networks.
IPv6 has almost nothing to do with QoS, despite what most people seem to think. Its only QoS-specific feature is the Flow Label, which allows RSVP-aware routers to more efficiently classify traffic. RSVP is not a great option for safeguarding QoS for routing traffic. Any realistic implementation of QoS today, outside VoIP, simply uses class of service (CoS) based loosely on the DiffServ model, using the TOS byte in IPv4 or the Traffic Class equivalent in IPv6.
Most routers in the Internet today are Cisco or Juniper, which have fairly reasonable CoS support - high-end Cisco routers have no trouble handling a few more queues, and Junipers can do four queues at wire speed through hardware support for CoS. The ability to throttle back worm-generated (or other) DoS traffic, or protecting routing traffic's QoS, is worth spending some CPU cycles for, as it avoids the massive load of BGP sessions stopping and then re-starting (every restart involves a full routing table update, which is very expensive in router CPU time).
CoS implementations are getting much simpler due to the availability of policy-based network management (PBNM) tools, which enable thousands of routers to be configured for CoS within less than an hour. (Disclosure: I work for a company that makes such tools.) The real issue is whether CoS is enough - as you suggest, an OOB network is better, particularly with respect to denial of service attacks. However, an OOB network is very expensive, and the trend is towards in-band management in packet networks for this reason, so a combination of IP QoS and extra IP security might be enough. You might also want to run IPSec between all BGP peers, and to have extra ACLs, so that only IPSec-authenticated BGP peers can connect using BGP. However, IPSec is quite an admin hassle, even though PBNM can help as well here - might be better to put anti-DoS features into routers to protect BGP, e.g. rate limits on inbound BGP traffic.
Finally, MPLS is not really about out-of-band routing - it does decouple routing and forwarding, but the routing (control) packets travel over the same network as the data packets. You could separate control traffic onto a separate network, but that's not something that MPLS requires or encourages. The main reasons to use MPLS are for traffic engineering, VPNs and harder end to end QoS, not OOB management.
The concept of OOB management is useful, but IMO it's best to consider building a 'virtual OOB network' that uses QoS and security to partition its resources, while using the same links and routers as the main traffic on the network.
QoS can cost virtually nothing in CPU cycles, as long as you have the right router - e.g. Junipers, or high-end Ciscos such as a 7500 with VIPs, using CEF. All that's needed is to have one queue for essential traffic (routing etc) and another for other traffic.
The real solution is to also dedicate some CPU to the router's routing processes, so that even when the forwarding path is being heavily hit by a worm, there is no impact on the routing side's use of CPU. QoS will then make sure that the BGP and other updates get through OK.
Cookies would be necessary, because some large ISPs (e.g. AOL) use a load-sharing NAT setup - you can request a page via one NAT box, then an image in the page via another NAT box, i.e. it looks to the web server as if two unrelated web clients accessed the page and image.
Cookies would be necessary, because some large ISPs (e.g. AOL) use a load-sharing NAT setup - you can request a page via one NAT box, then an image in the page via another NAT box, i.e. it looks to the web server as if two unrelated web clients accessed the page and image.
I recently installed DirectX on my sister's PC so her kids could play a particular game that required it. After four hours of downloading, installing, re-installing, upgrading (of course you can't uninstall DirectX - amazing...), changing sound card, upgrading drivers, etc, the PC was left with no sound in ANY games at all. This is a classic - Microsoft makes it 'easy' to upgrade and your system is left in a mess that can't be undone without a Windows re-install.
With this sort of philosophy, it's easy to understand why IIS/NT patching is also a mess.
This particular project has got little to do with 3G, because it is not mainly about mobility - the project used point-to-point fixed wireless (45 Mbps) for backbone links, and long-distance 802.11b (and plain 802.11b) for access links. The idea is to link schools and research centres to the Internet, rather than support mobile users.
There is a threat to 3G from wireless LANs, but that's from operators like MobileStar, who are setting up access points in 4,000 Starbucks locations across the US (and similar operators in Europe, some with 3G licenses). If 802.11b can get its power requirements down, and if coverage improves, it could prove to be a real competitor to 3G, particularly because its hardware and spectrum costs are already very low compared to 3G.
Step 2 (blocking some traffic only) will only work if you can put the block at the first-hop ISP router, and the customer's connection is dedicated (e.g. leased lines or dialup). ADSL and cable modems have shared bandwidth before the traffic hits the ISP, so DoS attacks from an infected server would infect all users. Interesting that packet-based infrastructures are so vulnerable to this, but the real issue is not being able to install filters close enough to the infected customers.
Relying on host features to prevent denial of service attacks is pointless - ISPs need to pull their finger out, and start doing filters that prevent source address spoofing. This will address the issue of raw sockets allowing such spoofing once and for all, across all OS types. Ever since it became possible to put a PC on the Internet, it has been a waste of time trying to rely on host security to prevent undesirable network behaviour.
Unfortunately this would not necessarily work, at least for ADSL networks that I'm familiar with. UK ADSL ISPs rent an ATM circuit from BT, which physically provides all ADSL connections - all the ISP's ADSL customers share one or two ATM circuits from BT's ADSL network into the ISP. My ISP's ATM circuits were completely full, due to a number of infected machines (100% packet loss) - only cutting off those machines would have worked as a way of returning network service. Under your scheme, the ATM circuits would still be full of traffic from the worm - this probably applies to any network topology with shared links upstream of the broadband RAS (remote access server), i.e. pretty much all of them. With cable modem networks, you'd have to actually disable the cable modem if the worm works fast enough to fill a local cable modem segment. Upstream rate limits on cable modems, unpopular as they are, would help here, but only if there are few infected systems.
I'm unimpressed with my ISP's inability to deliver service despite a worm infecting some customers - clearly they don't have any firewall or router able to filter traffic at this rate. It's complicated by the use of NAT routers on the customer premises, which means that most ADSL customers have dynamic addresses, but it should still have been possible to block existing traffic using blackhole routes that propagate via OSPF etc to the B-RAS) at the same time as disabling the user's account in RADIUS (so that when they reboot the router they are prevented from reconnecting via PPP over ATM).
Anyway - having lost Internet connectivity for a day, I'm all for ISPs aggressively disconnecting customers. Even better, put standard upstream rate limits and filtering on the router/modem at the customer premises, and make these remotely controllable for situations like this.
Re:WAP could have been cool
on
WAP Bashing
·
· Score: 2
Yes, that's really convenient - just dial a 10 digit number, and probably authenticate as well for larger purchases, and you've paid for something! Much easier than simply taking out your credit card and having the assistant swipe it through the machine...
Perhaps Bluetooth-enabled phones could be used for payment, but anything involving the user typing more than a 4 digit PIN is a non-starter.
Europe probably had WAP phones long before the US (from Q2 2000), and there are still a lot out there - however, very few people use them, due to poor usability, terrible implementations (many sites just can't be accessed due to browser or WAP gateway bugs), and unexciting content.
WAP may be slightly improved by adopting GPRS, which allows an always-on connection to the Net, but it is still fundamentally a pain to use. WAP 2.0 may improve things a bit, as it is closer to NTT's i-mode model of using standard TCP/IP connections (as an option) rather than buggy WAP gateways, and also can use XHTML not just WML. But don't hold your breath - PDAs and HTTP/TCP may be a better way to go.
Ethernet QoS is rarely deployed, but that's largely because there is less need for QoS in the LAN - most switches and links have more capacity than they really need, so as you point out only videoconferencing, VoIP and other non-streaming multimedia really need QoS.
Many Ethernet switches support 802.1p (a priority field within the 802.1Q VLAN header), allowing basic prioritisation. The larger L3-aware switches also support IP Precedence or even DiffServ (e.g. the Catalyst 6500). In the longer term, as policy-based management becomes more widely deployed, it's likely that switches will have 802.1p turned on, largely to support VoIP (since that is actually being deployed on some networks).
Interestingly, the 'bug open for years' syndrome also affected proprietary Unixes - you would find the same bugs across all the different Unixes in some cases (particularly in command line tools), although in some ways bug portability was a help, as you knew what to expect.
Some bugs only affect a tiny minority of people, just like some 'orphan diseases' that may affect only tens of people world wide. Along with bugs that are perceived as trivial, such bugs sometimes get very little attention from a vendor, for commercial reasons. Some vendors are better than others, particularly small vendors for whom any customer is pretty important, or those with good contact with their users (e.g. some shareware vendors). A key benefit of open source is that it tends to bring users into closer contact with developers, and of course users can just become developers (or hire a developer) to fix problems.
The interview was by Robert Fisk, who has written many extremely thoughtful pieces on the Middle East, including one recently on how the suicide bomber is a weapon against which the West has essentially no defence and no equivalent. That article is online at www.zmag.org - most of his articles should be online at www.independent.co.uk.
I suspect that a low-tech approach is more than enough for organising the attacks on Tuesday - it seems that bin Laden acts almost as a venture capitalist, funding and putting groups together, then lets them get on with it. I don't see why such groups would have needed encryption to communicate.
Re:Has Slashdot's own search been removed for good
on
Handling the Loads
·
· Score: 2
Exactly... Slashdot should start showing the year - now that it has been going for more than a year:)
The majority of ISPs run Cisco routers. Cisco's IOS software only supported IPv6 in 12.2T, which is the latest bleeding edge release, and even then it has 2 more phases to support full hardware acceleration and various routing protocols.
So... Most routers in the world don't support IPv6. Most hosts don't either - Windows XP is the first MS OS that supports IPv6, although Linux 2.2 and Solaris 8 and many other Unixes already do.
IPv6 adoption is NOT a big bang affair, although it is a lot of work - you can deploy IPv4+IPv6 routers and hosts and then gradually convert them so that IPv6 is enabled, and then much later turn off IPv4 is enabled. It's a huge job to get all the apps and hosts converted, but once converted, you can drive the choice of IPv6 vs. IPv4 for a given session using DNS - just return an IPv6 entry and the v6-capable apps will use IPv6.
Within a few years, all host OSs and most apps should be IPv6-capable without any extra work, enabling this to happen quite smoothly (though with a lot of work from network administrators and some from sys admins).
Does PPTP even work with IPv6? I doubt it, since it's not an IETF standard. An easier way to create tunnels is to use 6to4 - this allows any two IPv6 networks to dynamically create a tunnel over the IPv4 backbone, making it very easy to do this sort of thing. You could probably use IPsec in transport mode to secure the tunnel as well, but in practice IPsec is not too good for freenet etc, as it demands either pre-arranged keys (symmetric or RSA certificates) or a centralised certificate authority. Check google for 'opportunistic ipsec', though.
There are several kinds of dynamic allocation here:
- dynamic IPv4 addresses, often used for dialup as you say, and hard to use for web serving
- IPv6 allocation of the bottom half of the IPv6 address (last 64 bits I think) - this is basically the MAC address of your Ethernet card (with some provisions to change this for privacy reasons). Not really dynamic unless you want it to change.
- IPv6 allocation of the top half of the address - this is derived from your ISP, and it is *very* easy to renumber your whole network (even thousands of machines) when you switch to a different ISP. This is crucial to make sure that the route to your machines doesn't need to be stored in core routing tables in the Internet, avoiding them growing too fast. Also not dynamic unless you want to change providers.
The first kind of dynamic allocation goes away completely. The MAC address type allocation is only dynamic if you want to preserve privacy, typically on a client. And the provider part allocation is slowly changing, over a number of days after you switch providers, with plenty of time for DNS servers to react.
The upshot of this is that static addresses are very common in IPv6 - you only have to change your address if you switch providers. A couple of points though:
- you might want to use a dynamic MAC address for outbound client requests, for privacy reasons, and a static IPv6 address (plus DNS name) for your web server (even on the same host, it's easy to have multiple addresses per interface)
- networks with two Internet connections, termed multi-homed, are still a big problem for core routing tables, since they incur one 'exception' route in the core routers. There's some work going on under the term PTOMAINE (a very tortured acronym) that should solve this in the next 5 years or so, 'ietf ptomaine' should find it.
Slashdot Mirror
Very interesting - ANDF (Architecture Neutral Distribution Format) was dreamt up during the Unix wars, by the OSF (who created a Unix clone called OSF/1, used only by Compaq Tru64 these days), and this compiler implements a format (TDF) that seems to be derived from this. The idea was that compilers would produce ANDF, an intermediate compiler output format, and vendors would then ship CDs containing ANDF 'binaries' - the customer installed on their Unix box, which could be Alpha, PA-RISC, x86, etc, and a special tool then did the last stage of compilation from ANDF to binary.
Not sure why this never took off, probably it was too much of a leap from existing technology and the Unix vendors saw it as commoditising their boxes. A few years later, Java's bytecode and use of JIT or install-time compilation came along and rendered this moot, though ANDF/TDF are probably still more flexible.
IPv6 will not solve this problem, which has nothing to do with NAT or load sharing. The key element of the solution is to provide a higher priority (CoS/QoS) for BGP traffic, and to somehow limit the amount of CPU spent on ARPing for non-existent IP addresses on the router's directly-connected subnets.
I am all for using IPv6 where appropriate, but it's irrelevant here. Putting in bigger pipes is expensive, and may well just make things worse (a Pentium III can just about saturate a gigabit ethernet link - what if some well-connected hosting centres get infected and start spamming the net via these larger pipes?).
Agreed, see http://slashdot.org/comments.pl?sid=22054&cid=2367 894 for some more info on this, in response to a post on out of band management networks.
IPv6 has almost nothing to do with QoS, despite what most people seem to think. Its only QoS-specific feature is the Flow Label, which allows RSVP-aware routers to more efficiently classify traffic. RSVP is not a great option for safeguarding QoS for routing traffic. Any realistic implementation of QoS today, outside VoIP, simply uses class of service (CoS) based loosely on the DiffServ model, using the TOS byte in IPv4 or the Traffic Class equivalent in IPv6.
Most routers in the Internet today are Cisco or Juniper, which have fairly reasonable CoS support - high-end Cisco routers have no trouble handling a few more queues, and Junipers can do four queues at wire speed through hardware support for CoS. The ability to throttle back worm-generated (or other) DoS traffic, or protecting routing traffic's QoS, is worth spending some CPU cycles for, as it avoids the massive load of BGP sessions stopping and then re-starting (every restart involves a full routing table update, which is very expensive in router CPU time).
CoS implementations are getting much simpler due to the availability of policy-based network management (PBNM) tools, which enable thousands of routers to be configured for CoS within less than an hour. (Disclosure: I work for a company that makes such tools.) The real issue is whether CoS is enough - as you suggest, an OOB network is better, particularly with respect to denial of service attacks. However, an OOB network is very expensive, and the trend is towards in-band management in packet networks for this reason, so a combination of IP QoS and extra IP security might be enough. You might also want to run IPSec between all BGP peers, and to have extra ACLs, so that only IPSec-authenticated BGP peers can connect using BGP. However, IPSec is quite an admin hassle, even though PBNM can help as well here - might be better to put anti-DoS features into routers to protect BGP, e.g. rate limits on inbound BGP traffic.
Finally, MPLS is not really about out-of-band routing - it does decouple routing and forwarding, but the routing (control) packets travel over the same network as the data packets. You could separate control traffic onto a separate network, but that's not something that MPLS requires or encourages. The main reasons to use MPLS are for traffic engineering, VPNs and harder end to end QoS, not OOB management.
The concept of OOB management is useful, but IMO it's best to consider building a 'virtual OOB network' that uses QoS and security to partition its resources, while using the same links and routers as the main traffic on the network.
QoS can cost virtually nothing in CPU cycles, as long as you have the right router - e.g. Junipers, or high-end Ciscos such as a 7500 with VIPs, using CEF. All that's needed is to have one queue for essential traffic (routing etc) and another for other traffic.
The real solution is to also dedicate some CPU to the router's routing processes, so that even when the forwarding path is being heavily hit by a worm, there is no impact on the routing side's use of CPU. QoS will then make sure that the BGP and other updates get through OK.
Cookies would be necessary, because some large ISPs (e.g. AOL) use a load-sharing NAT setup - you can request a page via one NAT box, then an image in the page via another NAT box, i.e. it looks to the web server as if two unrelated web clients accessed the page and image.
Cookies would be necessary, because some large ISPs (e.g. AOL) use a load-sharing NAT setup - you can request a page via one NAT box, then an image in the page via another NAT box, i.e. it looks to the web server as if two unrelated web clients accessed the page and image.
I recently installed DirectX on my sister's PC so her kids could play a particular game that required it. After four hours of downloading, installing, re-installing, upgrading (of course you can't uninstall DirectX - amazing...), changing sound card, upgrading drivers, etc, the PC was left with no sound in ANY games at all. This is a classic - Microsoft makes it 'easy' to upgrade and your system is left in a mess that can't be undone without a Windows re-install.
With this sort of philosophy, it's easy to understand why IIS/NT patching is also a mess.
XP doesn't have support for Bluetooth (raised a bit of press when MS supported 802.11b instead), allegedly due to Bluetooth's immaturity.
This particular project has got little to do with 3G, because it is not mainly about mobility - the project used point-to-point fixed wireless (45 Mbps) for backbone links, and long-distance 802.11b (and plain 802.11b) for access links. The idea is to link schools and research centres to the Internet, rather than support mobile users.
There is a threat to 3G from wireless LANs, but that's from operators like MobileStar, who are setting up access points in 4,000 Starbucks locations across the US (and similar operators in Europe, some with 3G licenses). If 802.11b can get its power requirements down, and if coverage improves, it could prove to be a real competitor to 3G, particularly because its hardware and spectrum costs are already very low compared to 3G.
Step 2 (blocking some traffic only) will only work if you can put the block at the first-hop ISP router, and the customer's connection is dedicated (e.g. leased lines or dialup). ADSL and cable modems have shared bandwidth before the traffic hits the ISP, so DoS attacks from an infected server would infect all users. Interesting that packet-based infrastructures are so vulnerable to this, but the real issue is not being able to install filters close enough to the infected customers.
Relying on host features to prevent denial of service attacks is pointless - ISPs need to pull their finger out, and start doing filters that prevent source address spoofing. This will address the issue of raw sockets allowing such spoofing once and for all, across all OS types. Ever since it became possible to put a PC on the Internet, it has been a waste of time trying to rely on host security to prevent undesirable network behaviour.
Unfortunately this would not necessarily work, at least for ADSL networks that I'm familiar with. UK ADSL ISPs rent an ATM circuit from BT, which physically provides all ADSL connections - all the ISP's ADSL customers share one or two ATM circuits from BT's ADSL network into the ISP. My ISP's ATM circuits were completely full, due to a number of infected machines (100% packet loss) - only cutting off those machines would have worked as a way of returning network service. Under your scheme, the ATM circuits would still be full of traffic from the worm - this probably applies to any network topology with shared links upstream of the broadband RAS (remote access server), i.e. pretty much all of them. With cable modem networks, you'd have to actually disable the cable modem if the worm works fast enough to fill a local cable modem segment. Upstream rate limits on cable modems, unpopular as they are, would help here, but only if there are few infected systems.
I'm unimpressed with my ISP's inability to deliver service despite a worm infecting some customers - clearly they don't have any firewall or router able to filter traffic at this rate. It's complicated by the use of NAT routers on the customer premises, which means that most ADSL customers have dynamic addresses, but it should still have been possible to block existing traffic using blackhole routes that propagate via OSPF etc to the B-RAS) at the same time as disabling the user's account in RADIUS (so that when they reboot the router they are prevented from reconnecting via PPP over ATM).
Anyway - having lost Internet connectivity for a day, I'm all for ISPs aggressively disconnecting customers. Even better, put standard upstream rate limits and filtering on the router/modem at the customer premises, and make these remotely controllable for situations like this.
Yes, that's really convenient - just dial a 10 digit number, and probably authenticate as well for larger purchases, and you've paid for something! Much easier than simply taking out your credit card and having the assistant swipe it through the machine...
Perhaps Bluetooth-enabled phones could be used for payment, but anything involving the user typing more than a 4 digit PIN is a non-starter.
Europe probably had WAP phones long before the US (from Q2 2000), and there are still a lot out there - however, very few people use them, due to poor usability, terrible implementations (many sites just can't be accessed due to browser or WAP gateway bugs), and unexciting content.
WAP may be slightly improved by adopting GPRS, which allows an always-on connection to the Net, but it is still fundamentally a pain to use. WAP 2.0 may improve things a bit, as it is closer to NTT's i-mode model of using standard TCP/IP connections (as an option) rather than buggy WAP gateways, and also can use XHTML not just WML. But don't hold your breath - PDAs and HTTP/TCP may be a better way to go.
Ethernet QoS is rarely deployed, but that's largely because there is less need for QoS in the LAN - most switches and links have more capacity than they really need, so as you point out only videoconferencing, VoIP and other non-streaming multimedia really need QoS.
Many Ethernet switches support 802.1p (a priority field within the 802.1Q VLAN header), allowing basic prioritisation. The larger L3-aware switches also support IP Precedence or even DiffServ (e.g. the Catalyst 6500). In the longer term, as policy-based management becomes more widely deployed, it's likely that switches will have 802.1p turned on, largely to support VoIP (since that is actually being deployed on some networks).
You are quite free to design your database like this, but it will perform very poorly on most available DBMSs.
Interestingly, the 'bug open for years' syndrome also affected proprietary Unixes - you would find the same bugs across all the different Unixes in some cases (particularly in command line tools), although in some ways bug portability was a help, as you knew what to expect.
Some bugs only affect a tiny minority of people, just like some 'orphan diseases' that may affect only tens of people world wide. Along with bugs that are perceived as trivial, such bugs sometimes get very little attention from a vendor, for commercial reasons. Some vendors are better than others, particularly small vendors for whom any customer is pretty important, or those with good contact with their users (e.g. some shareware vendors). A key benefit of open source is that it tends to bring users into closer contact with developers, and of course users can just become developers (or hire a developer) to fix problems.
The interview was by Robert Fisk, who has written many extremely thoughtful pieces on the Middle East, including one recently on how the suicide bomber is a weapon against which the West has essentially no defence and no equivalent. That article is online at www.zmag.org - most of his articles should be online at www.independent.co.uk.
I suspect that a low-tech approach is more than enough for organising the attacks on Tuesday - it seems that bin Laden acts almost as a venture capitalist, funding and putting groups together, then lets them get on with it. I don't see why such groups would have needed encryption to communicate.
Exactly... Slashdot should start showing the year - now that it has been going for more than a year :)
One of the few sites that was accessible on Tuesday was washingtonpost.com - they Akamaized every page on the site (not just the graphics).
That's because of how everything2.com works. See www.zmag.org for the original article, and some other good analysis of the events of this week.
The majority of ISPs run Cisco routers. Cisco's IOS software only supported IPv6 in 12.2T, which is the latest bleeding edge release, and even then it has 2 more phases to support full hardware acceleration and various routing protocols.
So... Most routers in the world don't support IPv6. Most hosts don't either - Windows XP is the first MS OS that supports IPv6, although Linux 2.2 and Solaris 8 and many other Unixes already do.
IPv6 adoption is NOT a big bang affair, although it is a lot of work - you can deploy IPv4+IPv6 routers and hosts and then gradually convert them so that IPv6 is enabled, and then much later turn off IPv4 is enabled. It's a huge job to get all the apps and hosts converted, but once converted, you can drive the choice of IPv6 vs. IPv4 for a given session using DNS - just return an IPv6 entry and the v6-capable apps will use IPv6.
Within a few years, all host OSs and most apps should be IPv6-capable without any extra work, enabling this to happen quite smoothly (though with a lot of work from network administrators and some from sys admins).
Does PPTP even work with IPv6? I doubt it, since it's not an IETF standard. An easier way to create tunnels is to use 6to4 - this allows any two IPv6 networks to dynamically create a tunnel over the IPv4 backbone, making it very easy to do this sort of thing. You could probably use IPsec in transport mode to secure the tunnel as well, but in practice IPsec is not too good for freenet etc, as it demands either pre-arranged keys (symmetric or RSA certificates) or a centralised certificate authority. Check google for 'opportunistic ipsec', though.
There are several kinds of dynamic allocation here:
- dynamic IPv4 addresses, often used for dialup as you say, and hard to use for web serving
- IPv6 allocation of the bottom half of the IPv6 address (last 64 bits I think) - this is basically the MAC address of your Ethernet card (with some provisions to change this for privacy reasons). Not really dynamic unless you want it to change.
- IPv6 allocation of the top half of the address - this is derived from your ISP, and it is *very* easy to renumber your whole network (even thousands of machines) when you switch to a different ISP. This is crucial to make sure that the route to your machines doesn't need to be stored in core routing tables in the Internet, avoiding them growing too fast. Also not dynamic unless you want to change providers.
The first kind of dynamic allocation goes away completely. The MAC address type allocation is only dynamic if you want to preserve privacy, typically on a client. And the provider part allocation is slowly changing, over a number of days after you switch providers, with plenty of time for DNS servers to react.
The upshot of this is that static addresses are very common in IPv6 - you only have to change your address if you switch providers. A couple of points though:
- you might want to use a dynamic MAC address for outbound client requests, for privacy reasons, and a static IPv6 address (plus DNS name) for your web server (even on the same host, it's easy to have multiple addresses per interface)
- networks with two Internet connections, termed multi-homed, are still a big problem for core routing tables, since they incur one 'exception' route in the core routers. There's some work going on under the term PTOMAINE (a very tortured acronym) that should solve this in the next 5 years or so, 'ietf ptomaine' should find it.