Re: Dynamic (changing) IPv6 prefix delegation
On Thu, 24 Nov 2011, Seth Mos wrote: Hi, Op 24 nov 2011, om 21:09 heeft Joel jaeggli het volgende geschreven: On 11/21/11 14:18 , Nathan Eisenberg wrote: Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? prefix delegation to a downstream device via dhcp-pd Joe Sixpack might not even realize that his device even does this. I actually added a dhcpv6 server that can do just this. Still considering if it should do that automatically. Contrary to proper networking, I frequently see double nat routers because they purchased a new wifi routers which is then daisy chained to the old one. Or do bridging. Or they had a non-wifi model and plugged in the port labeled (internet) of the new wifi router into the existing one. Which is more common. With dhcp-pd in each, you could daisy chain a few times before it gives out. You know what, let's just build that because I can, it's a few hours of coding, but nothing too serious. Most hooks are already in place. I just didn't start a dhcpdv6 automatically yet. In a nutshell. Yes, Please. Regards, Seth
Re: Dynamic (changing) IPv6 prefix delegation
On 11/21/11 14:18 , Nathan Eisenberg wrote: Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? prefix delegation to a downstream device via dhcp-pd Nathan
Re: Dynamic (changing) IPv6 prefix delegation
Hi, Op 24 nov 2011, om 21:09 heeft Joel jaeggli het volgende geschreven: On 11/21/11 14:18 , Nathan Eisenberg wrote: Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? prefix delegation to a downstream device via dhcp-pd Joe Sixpack might not even realize that his device even does this. I actually added a dhcpv6 server that can do just this. Still considering if it should do that automatically. Contrary to proper networking, I frequently see double nat routers because they purchased a new wifi routers which is then daisy chained to the old one. Or they had a non-wifi model and plugged in the port labeled (internet) of the new wifi router into the existing one. Which is more common. With dhcp-pd in each, you could daisy chain a few times before it gives out. You know what, let's just build that because I can, it's a few hours of coding, but nothing too serious. Most hooks are already in place. I just didn't start a dhcpdv6 automatically yet. In a nutshell. Yes, Please. Regards, Seth
Re: Dynamic (changing) IPv6 prefix delegation
Nathan Eisenberg nat...@atlasnetworks.us writes: What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? What does Joe's ISPack save the missing bits for? Bjørn
Re: Dynamic (changing) IPv6 prefix delegation
On Monday 21 Nov 2011 20:27:55 Owen DeLong wrote: I suspect that mDNS/Rendezvous will become much more widespread in the IPv6 household and will become the primary service discovery mechanism. It actually works quite well and is relatively resilient to either frequent renumbering or the ill-advised use of ULA. A while ago there was some discussion of wouldn't mDNS/Rendezvous/Bonjour that doesn't suck be nice? on the list. I for one agree with Owen that it's important for a whole lot of things and will get more so in trying to deliver the promises of IPv6. (If you want network everywhere you probably need zero-configuration everywhere, and the network that's everywhere is IP.) I also think it's an underestimated contribution to the success of Apple in the iDevice era, much as network people tend to hate it. So perhaps we could identify what it is about mDNS service discovery that we hate and what could be improved. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them signature.asc Description: This is a digitally signed message part.
Re: Dynamic (changing) IPv6 prefix delegation
On Mon, Nov 21, 2011 at 10:21 AM, Seth Mos seth@dds.nl wrote: What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. I often hear if you need a static IP, you need business class server; bundled with we don't provide business service to residential customers. Almost makes one think there ought to be some consumer protection laws regulating it. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. Break the internet is about how I'd phrase it. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). 8) Don't use the wrong ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination.
Re: Dynamic (changing) IPv6 prefix delegation
Hello, On 11/21/11 16:21, Seth Mos wrote: Hello List, As a pfSense developer I recently ran into a test system that (actually) gets a IPv6 prefix from it's ISP. (Hurrah). What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? I think it should be to option for the end users. Select if they want stable IPv6 prefix or random IPv6 prefix. One of the thoughts that came to mind is T-Online in Germany that still disconnects it's (PPPoE) user base every 24 hours for a new random IP. This is kind of solution for preserving IPv4 addresses. Side effect of the changing IP address is that user can be tracked back if ISP is logging the actual IP binding. Short of setting really short timers on the RA messages for the LAN I can see a multitude of complications for consumers in the long run. People that configure their NAS, Media Player and Printer on their own network. And using ULA for either is not workable unless they somehow manage to grow DNS skill on the end user. Their NAS probably wants to download from the 'net and access videos from the NAS. The media player wants to be able to access youtube and the laptop needs to (reliably) find it's printer each time. I really hope that ISPs will commit to assigning the same prefix to the same user on each successive connection. Agree. Kind Regards, Janos Mohacsi
Re: Dynamic (changing) IPv6 prefix delegation
Worst case, you can always get an IPv6 static /48 from at least one provider without any additional cost. Owen On Nov 22, 2011, at 7:05 AM, Ray Soucy wrote: On Mon, Nov 21, 2011 at 10:21 AM, Seth Mos seth@dds.nl wrote: What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. I often hear if you need a static IP, you need business class server; bundled with we don't provide business service to residential customers. Almost makes one think there ought to be some consumer protection laws regulating it. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Dynamic (changing) IPv6 prefix delegation
snip On 22 Nov 2011, at 13:38, Joel Maslak wrote: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). snip Add to your list: 1.5) Instead of getting IPv6, getting private IPv4 and CGN service. -as
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I like being able to reach things in my house when I'm on the road. Having the prefix not bounce around turns out to be convenient for that. I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. That's beyond tragic if it's actually true. You should name and shame your provider if that's really the case. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). I haven't run into too many of these in the real world any more other than actual tiered services where you have the option of buying a higher bandwidth service. What I mostly see these days is hard-limits on negotiated speed of the connection. 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. Break the internet is about how I'd phrase it. The app would never become popular because most people would be unable to use it. It wouldn't break the internet. The internet would break the app. in its current state. Whether either of those possibilities is good or bad is left as an exercise for the reader. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). Mostly it means that your provider sort of gets IPv6, but, not really. If you want to provide me with contact information off-list, I'll attempt to engage in an educational outreach. 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. Yes, sounds like your provider needs to be hit with a clue-by-four. I don't think that typifies the rest of the world, though it's not as uncommon as I would like, either. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). Yes, this is an increasingly common problem. Thanks, Micr0$0ft. 8) Don't use the wrong ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. Huh? I haven't seen this problem at all. I've seen packets arrive with the ToS bits stripped, but, I haven't seen ToS cause a packet to get dropped. You seem to have found a particularly bleak set of providers to use. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination. I expect my packets to get delivered (and they generally do) and I have static addresses too. You can have it all if you try. Owen
Re: Dynamic (changing) IPv6 prefix delegation
On Tue, 22 Nov 2011 08:19:25 PST, Owen DeLong said: On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? pgpRef9eoBJEx.pgp Description: PGP signature
Re: Dynamic (changing) IPv6 prefix delegation
3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). This hasn't been my experience unless you're behind some form of NAT. Yes, it is well known that NAT breaks most protocols. I've come across a non-zero number of residential providers, who, with or without NAT, explicitly discard protocols 50 and 51. The same argument is applied - if you want this, you must buy a business connection. Which is usually double-speak for add an order of magnitude to the price, turn off *some* of the broken-ness. Regards, Tim.
Re: Dynamic (changing) IPv6 prefix delegation
On Tue, Nov 22, 2011 at 11:36 AM, valdis.kletni...@vt.edu wrote: A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? This. My options for home are Time Warner Cable 15M down, 1M up; or Fairpoint DSL, 3M down, 128K up. So my option is really only TWC. And I live 3 miles off the University of Maine campus. Other parts of the state don't have the luxury of more than one option, if any. You can't vote with your wallet if you're stuck with a monopoly. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:36 AM, valdis.kletni...@vt.edu wrote: On Tue, 22 Nov 2011 08:19:25 PST, Owen DeLong said: On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? I could understand how it MIGHT make more money to force customers that want static to purchase business class, but, if you then refuse to offer them business class service, that doesn't sound like more money, it just sounds like angry customers. A number of providers seem to be doing just fine with that business model over on the IPv4 side of the fence. And since they're usually a near-monopoly in their service area, angry customers aren't likely to actually vote with their wallets. Why is there any expectation that it will be any different in the IPv6 world? I didn't say they wouldn't make money... I said they wouldn't make MORE money. Owen
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:19 AM, Owen DeLong wrote:
Exactly. ISPs are in business to make as much money as they can - go figure.
How do you make more money by refusing to meet customer requests?
Not rocket science. The vast majority of customers fall into a small number of
categories. You make money by optimizing for those categories. For the folks
that don't fit in those categories (e.g., people who actually ask for IPv6),
you treat them as special cases until there are sufficient requests to justify
a new category.
1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years
or so when the equipment my line on is old enough to be replaced under a 15
or 20 year replacement cycle.
That's beyond tragic if it's actually true. You should name and shame your
provider if that's really the case.
I suspect most (all?) very large scale service providers amortize their
equipment over quite long periods. If said equipment doesn't support
feature, it becomes a relatively simple cost/benefit analysis to determine
whether or not upgrading the hardware out of cycle would have sufficient ROI to
justify the cost. A lot depends on how many customers will bolt if feature
isn't offered before the equipment is put out to pasture naturally. Since
(currently) the vast majority of large scale providers' customers have no
interest in (or even knowledge of) IPv6, it's unlikely the cost/benefit
analysis ends up in a pro-IPv6 way.
There are, of course, more forward looking ISPs, but they appear to be the
exception rather than the rule.
3) If you write an application using anything other than UDP or TCP, it
won't work on most networks (with some minor exceptions for PPTP and IPSEC,
which work sometimes).
This hasn't been my experience unless you're behind some form of NAT. Yes, it
is well known that NAT breaks most protocols.
Not NAT. Default deny firewalls. Look at the recommended firewall configs
from pretty much any security consultant/vendor and see what happens when you
try to turn on (say) SCTP.
4) What would happen if someone wrote a popular app that used IP options? I
don't want to know that answer even though I already know it. Break the
internet is about how I'd phrase it.
The app would never become popular because most people would be unable to use
it.
Right. See 'default deny firewalls'.
6) The same server can't receive IP fragments, except for the first one.
For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6
will cause longer answers). Yes, I know I can turn off large UDP responses
on my resolver. I bet more than a few people don't know that though.
I believe at least one resolver (BIND) will do this for you. It first tries
using an extension that allows for a 4096-byte buffer. If that fails, it tries
using the extension with a 512-byte buffer. If that fails, it turns off the
extension. In the latter 2 cases, if the response is larger than 512 bytes, DNS
will automatically fall back to TCP. Increases latency, but that's life on the
Real Internet(tm).
7) Even UDP and TCP aren't going to work everywhere. Hense why everything
seems to tunnel over HTTP or HTTPS even when that's an inappropriate method
(such as when reliable ordered packet delivery is a hinderence).
Yes, this is an increasingly common problem. Thanks, Micr0$0ft.
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be the
real IPng.
Regards,
-drc
Re: Dynamic (changing) IPv6 prefix delegation
Owen DeLong o...@delong.com naively wrote: On Nov 22, 2011, at 7:38 AM, Joel Maslak wrote: On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. How do you make more money by refusing to meet customer requests? By 'encouraging' those 'high cost / low profit' customers to 'go elsewhere', and devoting the resources that they would otherwise consume to supporting 'lower-cost/ higher-profit' customers. This is 'no-brainer' free-market economics. :)
Re: Dynamic (changing) IPv6 prefix delegation
3) If you write an application using anything other than UDP or TCP, it
won't work on most networks (with some minor exceptions for PPTP and IPSEC,
which work sometimes).
This hasn't been my experience unless you're behind some form of NAT. Yes,
it is well known that NAT breaks most protocols.
Not NAT. Default deny firewalls. Look at the recommended firewall configs
from pretty much any security consultant/vendor and see what happens when you
try to turn on (say) SCTP.
No, NAT. Yes, default deny firewalls can add additional breakage, but, even if
you add the requisite permits in many cases NAT will still break most things
for which ALGs haven't been provided in the NAT box. Default deny firewalls are
a configuration problem that can be easily addressed through configuration. NAT
is a fundamental damage to network services which requires modifying the actual
NAT device or its firmware to work around or the elimination of NAT to resolve.
7) Even UDP and TCP aren't going to work everywhere. Hense why everything
seems to tunnel over HTTP or HTTPS even when that's an inappropriate method
(such as when reliable ordered packet delivery is a hinderence).
Yes, this is an increasingly common problem. Thanks, Micr0$0ft.
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to enable/encourage
this trend?
Owen
Re: Dynamic (changing) IPv6 prefix delegation
On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said:
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to enable/encourage
this trend?
Actually, I'd nominate the creator of the PIX firewall box for that honor,
mostly because it made it socially acceptable to do firewalling that caused
other sites pain and suffering (SMTP fixups, anybody? :)
pgpX6O3mDI4Ie.pgp
Description: PGP signature
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 12:30 PM, valdis.kletni...@vt.edu wrote:
On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said:
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to
enable/encourage this trend?
Actually, I'd nominate the creator of the PIX firewall box for that honor,
mostly because it made it socially acceptable to do firewalling that caused
other sites pain and suffering (SMTP fixups, anybody? :)
That would be John Mayes. The PIX was an outgrowth of Cisco's purchase of
a company called Network Address Translation (translation.com back in the
day). Frankly, the trend towards NAT and the need for some level of security
that was evolving in that day made most of those things inevitable.
Were there better approaches, perhaps. However, even with the PIX in place,
I think that Micr0$0ft did more to make http-based tunneling a widespread and
common phenomenon. It may have been pragmatic from their perspective, but,
it was also damaging to the internet and they were the ones that chose to be
pragmatic like that on a wide scale.
Owen
Re: Dynamic (changing) IPv6 prefix delegation
*** *** right. *** like * ** to ** *** what *** * ***
** **.
:)
--
Brielle
(sent from my phone)
On Nov 22, 2011, at 1:30 PM, valdis.kletni...@vt.edu wrote:
On Tue, 22 Nov 2011 10:43:35 PST, Owen DeLong said:
Not sure why you'd blame Microsoft. HTTP{,S} is increasingly looking to be
the real IPng.
Perhaps because they have done more than any other vendor to
enable/encourage this trend?
Actually, I'd nominate the creator of the PIX firewall box for that honor,
mostly because it made it socially acceptable to do firewalling that caused
other sites pain and suffering (SMTP fixups, anybody? :)
Dynamic (changing) IPv6 prefix delegation
Hello List, As a pfSense developer I recently ran into a test system that (actually) gets a IPv6 prefix from it's ISP. (Hurrah). What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? One of the thoughts that came to mind is T-Online in Germany that still disconnects it's (PPPoE) user base every 24 hours for a new random IP. Short of setting really short timers on the RA messages for the LAN I can see a multitude of complications for consumers in the long run. People that configure their NAS, Media Player and Printer on their own network. And using ULA for either is not workable unless they somehow manage to grow DNS skill on the end user. Their NAS probably wants to download from the 'net and access videos from the NAS. The media player wants to be able to access youtube and the laptop needs to (reliably) find it's printer each time. I really hope that ISPs will commit to assigning the same prefix to the same user on each successive connection. Here is to hoping. Kind regards, Seth
Re: Dynamic (changing) IPv6 prefix delegation
Seth Mos seth@dds.nl writes: Hello List, As a pfSense developer I recently ran into a test system that (actually) gets a IPv6 prefix from it's ISP. (Hurrah). What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? I certainly hope not. But you should be prepared to handle the situation anyway. Even those ISPs providing a stable prefix may have to change it from time to time. Which means that there is always a risk that the prefix changes with a new PPPoE session, even if that doesn't happen every time. And if the prefix does change, then the old prefix will most likely not be routed out the new PPP interface even if the lease hasn't expired yet. You'll probably want to deprecate the old prefix when this happens, signalling to the hosts that they should prefer the new prefix for new sessions. Bjørn
Re: Dynamic (changing) IPv6 prefix delegation
On 21/11/2011 16:33, Bjørn Mork wrote: But you should be prepared to handle the situation anyway. s/be prepared to handle the situation/plan to handle this as default/ Nick
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 21, 2011, at 7:21 AM, Seth Mos wrote: Hello List, As a pfSense developer I recently ran into a test system that (actually) gets a IPv6 prefix from it's ISP. (Hurrah). What is bewildering to me is that each time the system establishes a new PPPoE session to the ISP they assign a different IPv6 prefix via delegation together with a differing IPv4 address for the WAN. Is this going to be forward for other consumer ISPs in the world? Unfortunately, there are some ISPs that believe this is the right thing to do. Some go so far as to claim that scrambling customer prefixes is a mechanism to help insure customer privacy. One of the thoughts that came to mind is T-Online in Germany that still disconnects it's (PPPoE) user base every 24 hours for a new random IP. Short of setting really short timers on the RA messages for the LAN I can see a multitude of complications for consumers in the long run. Yep... It remains to be seen whether they will persist in this ill-conceived behavior after the support calls start rolling in. People that configure their NAS, Media Player and Printer on their own network. And using ULA for either is not workable unless they somehow manage to grow DNS skill on the end user. Their NAS probably wants to download from the 'net and access videos from the NAS. The media player wants to be able to access youtube and the laptop needs to (reliably) find it's printer each time. I suspect that mDNS/Rendezvous will become much more widespread in the IPv6 household and will become the primary service discovery mechanism. It actually works quite well and is relatively resilient to either frequent renumbering or the ill-advised use of ULA. I really hope that ISPs will commit to assigning the same prefix to the same user on each successive connection. It would be nice, but, I suspect there will always be some fraction of residential ISPs determined not to do the right thing. Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen
Re: Dynamic (changing) IPv6 prefix delegation
On Mon, Nov 21, 2011 at 12:27:55PM -0800, Owen DeLong wrote: Unfortunately, there are some ISPs that believe this is the right thing to do. Some go so far as to claim that scrambling customer prefixes is a mechanism to help insure customer privacy. s/ISPs/governments, privacy people and influential media outlets/ There is significant political pressure (at least over here) to continue that IPv4 habit for IPv6 as well. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 21, 2011, at 12:47 PM, Daniel Roesen wrote: On Mon, Nov 21, 2011 at 12:27:55PM -0800, Owen DeLong wrote: Unfortunately, there are some ISPs that believe this is the right thing to do. Some go so far as to claim that scrambling customer prefixes is a mechanism to help insure customer privacy. s/ISPs/governments, privacy people and influential media outlets/ There is significant political pressure (at least over here) to continue that IPv4 habit for IPv6 as well. Yes, IMHO, Germany has some of the most misguided privacy laws and habits in human history. In the rest of the world, it is primarily ISPs that are repeating this mantra, but, hopefully reality will eventually set in and correct the situation even in Germany. Owen
RE: Dynamic (changing) IPv6 prefix delegation
Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? Nathan
Re: Dynamic (changing) IPv6 prefix delegation
On Mon, Nov 21, 2011 at 22:18, Nathan Eisenberg nat...@atlasnetworks.us wrote: Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? Flexibility. With dhcpv6 prefix delegation, you are going to want devices to be able to request (at least) /60s for further delegation (and better yet /56s to allow them to delegate /60s with further delegation when needed). While Joe may not have as complex of an environment as his neighbor Sue, should we target the common Joe, or the advanced Sue? As I suspect Owen will say, there is no reason *not* to give out /48s (ipv6 space is huge), and this is good opportunity to enable the residential user to not have to work around artificial limits in the future. Gary
RE: Dynamic (changing) IPv6 prefix delegation
What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? Flexibility. With dhcpv6 prefix delegation, you are going to want devices to be able to request (at least) /60s for further delegation (and better yet /56s to allow them to delegate /60s with further delegation when needed). While Joe may not have as complex of an environment as his neighbor Sue, should we target the common Joe, or the advanced Sue? As I suspect Owen will say, there is no reason *not* to give out /48s (ipv6 space is huge), and this is good opportunity to enable the residential user to not have to work around artificial limits in the future. Gary Prefix delegation for what? What does Sue do at home that requires 2 levels of prefix delegation inside the house? Does Sue really need to be able to have 65536 subnets instead of 256 in her home? Nathan
Re: Dynamic (changing) IPv6 prefix delegation
Sent from my iPhone On Nov 21, 2011, at 14:18, Nathan Eisenberg nat...@atlasnetworks.us wrote: Look at the number that are refusing to make generous prefix allocations to residential end users and limiting them to /56, /60, or even worse, /64. Owen, What does Joe Sixpack do at home with a /48 that he cannot do with a /56 or a /60? Nathan First, the better question is what advantage is there in building such limiting present day limitations into the future? Second, the answer is facilitate a broad range of automated hierarchical topologies allowing for both breadth and depth of prefix distribution among partitions within the home environment. I admit we have not even begun to scratch the surface of how, where, or why these topologies may evolve, but I can see that due to the tendency for software to be developed to the lowest common denominator, if we make said denominator too low, we will forever blockade the opportunities for such innovations to see the light of day. Owen
