end-user ipv6 deployment and concerns about privacy
Hello! As the first IPv6 deployments for end-users are in the planning stage in Germany, I realized I have not found any BCP for handling addressing in those scenarios. IPv6 will make it a lot easier for static address deployments but I wonder weather this is in the best sense for the customers. As I normally come from the technical side I prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A major provider of dsl here in Germany recently blogged about this [1]. Their proposal is to serve two subnets, one being a static one while the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools). This is not about using privacy extensions as the subnet is sufficient for identification. Did you reach any conclusion on this matter? Thanks, Hannes [1] http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://blog.1und1.de/2010/05/07/ipv6-totale-ueberwachung/&sl=de&tl=en
On Wed, 18 Aug 2010, Hannes Frederic Sowa wrote:
Did you reach any conclusion on this matter?
Let the user choose. Here in Sweden we've for 10 years had ISPs offering static IPv4 address (either handed out via DHCP or just plain static with no dynamics what so ever) and some users prefer that, some don't. Some sell static IP as an extra option, some don't. For people who want to use DNS and run services, they'll most likely want a static address/subnet that doesn't change in the first place (even though it should be handed out via DHCPv6-PD for ease). If someone wants to be anonymous, there is always TOR or other anonymising services. Personally I prefer static for both IPv4 and IPv6 and have chosen providers accordingly historically. I also recommend this to others. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, Aug 18, 2010 at 7:12 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
For people who want to use DNS and run services, they'll most likely want a static address/subnet that doesn't change in the first place (even though it should be handed out via DHCPv6-PD for ease). If someone wants to be anonymous, there is always TOR or other anonymising services.
Tor is fairly slow using it for every days internet surfing. Why don't have sensible defaults for most users as default. For them I don't see a need for static prefixes.
Personally I prefer static for both IPv4 and IPv6 and have chosen providers accordingly historically. I also recommend this to others.
On the technical side it is clear. Static is the way to go.
On Wed, Aug 18, 2010 at 7:53 AM, Marco Hogewoning <marcoh@marcoh.net> wrote:
On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote:
prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A
What does facebook have to do with it ? Ever heard of cookies ?
Facebook as an example of a company whose founder stated that privacy is old-fashioned. Cookies sit on another network-layer I am currently not talking about. They can be removed more easily, most simply by reinstalling your computer. The user *can* do something about cookies.
On 18 aug 2010, at 09:35, Hannes Frederic Sowa wrote:
On Wed, Aug 18, 2010 at 7:53 AM, Marco Hogewoning <marcoh@marcoh.net> wrote:
On 18 aug 2010, at 01:12, Hannes Frederic Sowa wrote:
prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A
What does facebook have to do with it ? Ever heard of cookies ?
Facebook as an example of a company whose founder stated that privacy is old-fashioned. Cookies sit on another network-layer I am currently not talking about. They can be removed more easily, most simply by reinstalling your computer. The user *can* do something about cookies.
Yeah but given the amount of NAT and dynamic addresses around in v4 land. I think it's highly unlikely you are better of tracking v4 addresses instead of pushing cookies, especially as most 2.0 sites require a login anyway. Groet, MarcoH
On Wed, 18 Aug 2010 01:12:19 +0200 Hannes Frederic Sowa <hannes@mailcolloid.de> wrote:
Hello!
As the first IPv6 deployments for end-users are in the planning stage in Germany, I realized I have not found any BCP for handling addressing in those scenarios. IPv6 will make it a lot easier for static address deployments but I wonder weather this is in the best sense for the customers. As I normally come from the technical side I prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A major provider of dsl here in Germany recently blogged about this [1]. Their proposal is to serve two subnets, one being a static one while the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools).
This is not about using privacy extensions as the subnet is sufficient for identification.
Did you reach any conclusion on this matter?
Haven't really thought about it before. One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.) As you've mentioned, privacy addresses help. A related idea is described in "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses. Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing. Regards, Mark. [0] http://www.cs.columbia.edu/~smb/papers/tarp.pdf
On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote:
Haven't really thought about it before.
One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.)
Yep, I am in favour of such setups. This will stress internal name services(eg. netbios) but would be a solvable problem, I think.
As you've mentioned, privacy addresses help. A related idea is described in "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses.
Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing.
If your ipv6-geolocation-service tells you that all /48 prefixes behind this network are just static home-user networks, why not just ignore the lower 64 bits or even the lower 80 bits? Privacy extensions would be no help here. In IPv4-land I have the possibility to reconnect and get a new unrelated ip-address every time. hannes
On Wed, 18 Aug 2010 16:18:00 +0200 Hannes Frederic Sowa <hannes@mailcolloid.de> wrote:
On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote:
Haven't really thought about it before.
One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported. CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.)
Yep, I am in favour of such setups. This will stress internal name services(eg. netbios) but would be a solvable problem, I think.
As you've mentioned, privacy addresses help. A related idea is described in "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses.
Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing.
If your ipv6-geolocation-service tells you that all /48 prefixes behind this network are just static home-user networks, why not just ignore the lower 64 bits or even the lower 80 bits? Privacy extensions would be no help here.
They help because you're concerned about privacy. You didn't qualify that you're only concerned about privacy from geolocation services, so I described a mechanism that would provide you as much privacy as possible, while also being automatic, and also continuing to provide IPv6 Internet connectivity. No where was cryto mentioned either (on both our parts), yet that is also a privacy mechanism. As a customer, it's relatively hard to hide from geolocation services because they use your IP address in combination with information that you don't have control over i.e. RIR / whois data. If a customer wants to hide from that, then they'll need to start tunnelling their traffic to another entry/exit point on the Internet. Much like security, privacy is relative. If you want to have bi-directional communications with another entity, you have to disclose your identity. How long you retain that identity is what makes one form of privacy more private than another. Customers who have high expectations of privacy won't trust their ISP at the time to preserve it - because, as the cliche goes, if you want something done properly, you need to do it yourself. So, as an ISP, you need to think about how much privacy you can provide, can afford to provide, and at what point it becomes irrelevant because your customer doesn't trust you to provide it at all.
In IPv4-land I have the possibility to reconnect and get a new unrelated ip-address every time.
They're issued by the same ISP, to they're related. Regards, Mark.
On Wed, Aug 18, 2010 at 11:16 PM, Mark Smith wrote:
They help because you're concerned about privacy. You didn't qualify that you're only concerned about privacy from geolocation services, so I described a mechanism that would provide you as much privacy as possible, while also being automatic, and also continuing to provide IPv6 Internet connectivity. No where was cryto mentioned either (on both our parts), yet that is also a privacy mechanism.
I tried to highlight the relationship between ipv4-address and /48-prefixes in regard to privacy. If a provider is known for handling out statically allocated prefixes, it should be possible to track its clients by prefix. Sorry for picking a geolocation-service as an example of where such information can originate from. It was misleading.
As a customer, it's relatively hard to hide from geolocation services because they use your IP address in combination with information that you don't have control over i.e. RIR / whois data. If a customer wants to hide from that, then they'll need to start tunnelling their traffic to another entry/exit point on the Internet.
Fully hiding from geolocation services is only possible with anonymity services, yes.
Much like security, privacy is relative. If you want to have bi-directional communications with another entity, you have to disclose your identity. How long you retain that identity is what makes one form of privacy more private than another. Customers who have high expectations of privacy won't trust their ISP at the time to preserve it - because, as the cliche goes, if you want something done properly, you need to do it yourself. So, as an ISP, you need to think about how much privacy you can provide, can afford to provide, and at what point it becomes irrelevant because your customer doesn't trust you to provide it at all.
But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity.
In IPv4-land I have the possibility to reconnect and get a new unrelated ip-address every time.
They're issued by the same ISP, to they're related.
Ups. Unrelated in the sense of random ip from their pool, of course. hannes
* Hannes Frederic Sowa (hannes@mailcolloid.de) wrote:
But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity.
Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover). But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point. Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway) just my $.02 /Joakim
On Aug 19, 2010, at 5:30 AM, Joakim Aronius wrote:
* Hannes Frederic Sowa (hannes@mailcolloid.de) wrote:
But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity.
Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).
But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.
You actually imagine wrong in most cases. Many do, but, not most. Most use mDNS for such things these days, actually.
Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway)
I would agree. I think that customers that WANT privacy at the expense of having their prefix change often being able to request such service might be a good value-add service you could offer, but, I think the vast majority of customers would prefer prefix stability. I think that the privacy implications of a stable prefix are vastly over-stated in this thread. Owen
Joakim Aronius wrote:
But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.
The wise setup will use routed and non-routed addressing internally. This is how IPv6 was designed to handle it. Devices will be found through multicast, dynamic dns, or other means. Jack
On 8/19/10 5:30 AM, Joakim Aronius wrote:
* Hannes Frederic Sowa (hannes@mailcolloid.de) wrote:
But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity.
Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).
But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.
manual configuration of ip address name mappings seems like a rather low priority for the average home user... I don't expect that will be a big activity in the future either, more devices means less manual intervention not more.
Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway)
just my $.02
/Joakim
* Joel Jaeggli (joelja@bogus.com) wrote:
manual configuration of ip address name mappings seems like a rather low priority for the average home user...
I don't expect that will be a big activity in the future either, more devices means less manual intervention not more.
Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 mindset and have not yet grasped the full blessing of IPv6, zeroconf etc. etc. Anyway, constantly changing prefixes for home users still seem like begging for trouble. (Could be a service though, as mentioned, but on the other hand I expect a fair number of anonymity services to arise so charging for it might be tough.) Cheers, /Joakim
On 08/19/2010 07:58 PM, Joakim Aronius wrote:
* Joel Jaeggli (joelja@bogus.com) wrote:
manual configuration of ip address name mappings seems like a rather low priority for the average home user...
I don't expect that will be a big activity in the future either, more devices means less manual intervention not more.
Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 mindset and have not yet grasped the full blessing of IPv6, zeroconf etc. etc.
Anyway, constantly changing prefixes for home users still seem like begging for trouble. (Could be a service though, as mentioned, but on the other hand I expect a fair number of anonymity services to arise so charging for it might be tough.)
Cheers, /Joakim
If you still want fairly static addressing for your local network, there is always ULA. And those addresses do not leak to the outside world. I'm surprised no one mentioned it, maybe I missed it. I can understand if people don't recommend them because you mentioned end-user, but it might be useful to a poweruser. You could have your DSL- or cable-router/-modem onetime generate a ULA and have RA/DHCPv6 distribute that to the devices in the network like the addresses it gets from the provider.
On 8/19/10 10:58 AM, Joakim Aronius wrote:
* Joel Jaeggli (joelja@bogus.com) wrote:
manual configuration of ip address name mappings seems like a rather low priority for the average home user...
I don't expect that will be a big activity in the future either, more devices means less manual intervention not more.
Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 mindset and have not yet grasped the full blessing of IPv6, zeroconf etc. etc.
I'm not sure I'd characterize zeroconf, or rendezvous or anything other technology for device mapping and discovery to be a blessing, that said the use case for "take shiny new toy out of the box an plug it in is not that different from the use case of device needs to discard it's old mapping and use a new one.
Anyway, constantly changing prefixes for home users still seem like begging for trouble. (Could be a service though, as mentioned, but on the other hand I expect a fair number of anonymity services to arise so charging for it might be tough.)
a device might get plugged in and be in the same location for the entirety of it service life or it might move ever couple hours as a number of increasing portable devices tend to do, the later set of devices already cope with a lack of address stability fairly well and pulling the run out from under them every once in a while supports renumbering behavior... I can remember early network printers using bootp and the assuming that they could use that one ip address forever. today the printer will dhcp and advertise it's availability in the same broadcast domain and may well reregister it's name in dynamic dns if possible.
Cheers, /Joakim
I can remember early network printers using bootp and the assuming that they could use that one ip address forever. today the printer will dhcp and advertise it's availability in the same broadcast domain and may well reregister it's name in dynamic dns if possible.
Funny... I remember printers only thinking that if they were going to get moved, they'd also likely get unplugged and get a new address after the move. Owen
On 8/21/10 11:52 PM, Owen DeLong wrote:
I can remember early network printers using bootp and the assuming that they could use that one ip address forever. today the printer will dhcp and advertise it's availability in the same broadcast domain and may well reregister it's name in dynamic dns if possible.
Funny... I remember printers only thinking that if they were going to get moved, they'd also likely get unplugged and get a new address after the move.
rfc 951 made no provision in the protocol for the recovery of an address. you may well get a new one but the old one is assigned forever until someone prunes the cruft
Owen
On Thu, 19 Aug 2010 14:30:07 +0200 Joakim Aronius <joakim@aronius.com> wrote:
* Hannes Frederic Sowa (hannes@mailcolloid.de) wrote:
But most people just don't care. My proposal is to have some kind of sane defaults for them e.g. changing their prefix every week or in the case of a reconnect. This would mitigate some of the many privacy concerns in the internet a little bit. Of course all the already known problems would still exist. And still people have to care about the technology to reach a higher level of anonymity.
Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).
But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.
Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway)
ULA - RFC4193. (People really need to stop thinking in IPv4 mode when discussing IPv6 ....)
just my $.02
/Joakim
On 8/18/10 4:20 PM, Hannes Frederic Sowa wrote:
On Wed, Aug 18, 2010 at 11:16 PM, Mark Smith wrote:
In IPv4-land I have the possibility to reconnect and get a new unrelated ip-address every time.
They're issued by the same ISP, to they're related.
Ups. Unrelated in the sense of random ip from their pool, of course.
except of course that in practice if your lease hasn't expired and the ip reassigned, or even if you manually release it you're very likely to receive the same one.
hannes
On Wed, 18 Aug 2010 20:04:47 +0930 Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Wed, 18 Aug 2010 01:12:19 +0200 Hannes Frederic Sowa <hannes@mailcolloid.de> wrote:
Hello!
As the first IPv6 deployments for end-users are in the planning stage in Germany, I realized I have not found any BCP for handling addressing in those scenarios. IPv6 will make it a lot easier for static address deployments but I wonder weather this is in the best sense for the customers. As I normally come from the technical side I prefer static addressing. But in the world of facebook and co. I wonder if it would be a better to let the user have the choice. A major provider of dsl here in Germany recently blogged about this [1]. Their proposal is to serve two subnets, one being a static one while the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools).
This is not about using privacy extensions as the subnet is sufficient for identification.
Did you reach any conclusion on this matter?
Haven't really thought about it before.
One thing to consider is that unless the preferred and valid lifetimes of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic - they'll eventually expire unless they're refreshed. The preferred and valid lifetimes for prefixes that are delegated to customers could be something that they might be able to change via a web portal, bounded to within what you as an ISP are happy with e.g. 1 to 30 days, rather than the absolute range of lifetime values supported.
In case it isn't clear, the customer would have multiple delegated IPv6 prefixes during the overlap period. New prefixes are phased in and old ones are phased out. Over what time period the phase in / phase out occurs is what the customer could have the ability to change. Changing addresses will disrupt ongoing communications. While IPv6 can't prevent that disruption, it does have mechanisms available to handle it far more gracefully than the customer having to bounce their PPP session to acquire new addressing. With the right parameters, I think an ISP could make phasing in/phasing out prefixes transparent for most cases.
CPE could also potentially do the same thing with the range of subnets it has been delegated, by phasing in and out subnets over time on it's downstream interfaces. (The more subnets the better, so a /48 would be ideal for this.)
As you've mentioned, privacy addresses help. A related idea is described in "Transient addressing for related processes: Improved firewalling by using IPv6 and multiple addresses per host." [0], Peter M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64 addresses in a /64, and has different applications on the same host use different source IPv6 addresses.
Pretending to be multiple hosts, or even just one with privacy addresses, moving around multiple subnets, on delegated prefixes that change fairly regularly would probably mitigate quite a lot of the privacy concerns people may have related to IPv6 addressing.
Regards, Mark.
Hannes Frederic Sowa wrote:
the other one will be dynamically allocated. I have no clue how the user would switch between these subnets (without using some kind of command line tools).
Web portals work fine, and honestly, it's not like you need to switch subnets, either. PPPoE/A implementations work great, as they are already designed to utilize radius backends to quickly alter static/dynamic on a session. For bridging setups, you have a variety of implementations and it becomes messier. Cisco, while maintaining RBE did away with the concept of proxy-nd, and didn't provide a mechanism for dynamically allocating the prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4. Jack
On Wed, Aug 18, 2010 at 11:41 PM, Jack Bates wrote:
Web portals work fine, and honestly, it's not like you need to switch subnets, either. PPPoE/A implementations work great, as they are already designed to utilize radius backends to quickly alter static/dynamic on a session. For bridging setups, you have a variety of implementations and it becomes messier. Cisco, while maintaining RBE did away with the concept of proxy-nd, and didn't provide a mechanism for dynamically allocating the prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4.
Thanks. I will have a deeper look in the standards. This sounds like a viable solution to me. Albeit, I wonder if there is a drive for the big ISPs to implement such features.
On Thu, 19 Aug 2010 01:35:50 +0200 Hannes Frederic Sowa <hannes@mailcolloid.de> wrote:
On Wed, Aug 18, 2010 at 11:41 PM, Jack Bates wrote:
Web portals work fine, and honestly, it's not like you need to switch subnets, either. PPPoE/A implementations work great, as they are already designed to utilize radius backends to quickly alter static/dynamic on a session. For bridging setups, you have a variety of implementations and it becomes messier. Cisco, while maintaining RBE did away with the concept of proxy-nd, and didn't provide a mechanism for dynamically allocating the prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4.
Thanks. I will have a deeper look in the standards. This sounds like a viable solution to me. Albeit, I wonder if there is a drive for the big ISPs to implement such features.
Potentially it's a value add that small ISPs can use to distinguish their basic packet transport services from their larger competitors.
On Wed, Aug 18, 2010 at 04:41:56PM -0500, Jack Bates wrote:
prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4.
This is surprising to me, can you comment on why DHCPv6 TA is being used in this scenario? -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/
participants (10)
-
David W. Hankins -
Hannes Frederic Sowa -
Jack Bates -
Joakim Aronius -
Joel Jaeggli -
Leen Besselink -
Marco Hogewoning -
Mark Smith -
Mikael Abrahamsson -
Owen DeLong