The average user will notice the lack of IPv6 when a CGN is put in the IPv4 path and things like port forwarding stop working. For some ISP's that is now. For others it is in the future. Until then you really shouldn't notice whether you are using IPv4 or IPv6 to reach another site or how you are reached. If you do notice then the ISP / OS vendor isn't doing their job properly.
Hopefully the ISP will take away the IPv6 knob and just deliver IPv6 to everyone in the near future. There aren't many IPv6 only reachable destinations yet but more are coming as more ISP's switch over to using CGN to deliver IPv4.
Apple II w/ 4K of memory would cost $5236.87 ($1298) in todays dollars. While this may be a lot less than a lot of computers at the time I wouldn't call it a cheap computer by any stretch of the imagination.
The way to defeat stupid laws like this is for everyone to actually send everything they intend to upload to the ratings board then to complain when you don't get a rating back in a timely manner to their representative.
It a combination of things. Sure you can photocopy a card if you can get access to it for long enough but requiring a pin forces the customer to go to the card reader or the card reader to be brought to you. This reduces the window when the card can be photocopied or the magstrip being fraudulently read. Add to that the CC# is tagged as requiring a pin so you can't just put the details onto a blank and use it.
The readers are very low powered so unless you actually put your wallet against the reader with multiple cards in it this isn't a issue. Just pull the card you want to use from the wallet. Yes, I have multiple contact less cards on me. A couple of credit cards and travel cards.
Actually you often had a email account and logged in and read it using a command line interface and yes email was left in the mail box.
After that came POP and IMAP, both of which supported leaving email on the server. The main reason for down loading was the ridiculously small amounts of email storage space offered.
The entire premise that email over a certain number of days is abandoned was always false.
I just replaced a cable modem that was 10+ years old. I've got other equipment that is still going strong after 15 years. The only thing that was done, other than the occasional clean out of dust, was to replace a single fan. So yes, 20 years should be possible and if not the replacement costs of the powered equipment is a lot less than the full cost of installation. Replacing a CPE device will be less than $100 and will most probably support a faster connection speed. Replacing a line card will be similar on a per port basis. The fibre will last 20 years without a worry. The major problems with fibre will be back hoes and if the plastic sheath attracts animals.
The act is "Broadband Network Companies Act 2011" so you can't really blame it for the ageing infrastructure. If you want to blame anyone for the ageing infrastructure blame the ISP's that failed to invest in new technologies.
This two decade old paper shows Telstra's plans for FTTH in 1994 INT94b.PDF. Telstra failed to act on this for two decades. The introduction of the NBN is a reaction to that failure to act and a recognition that the costs are such that you needed a longer term outlook than next quarter's earnings. The NBN also got caught up in partisan politics which hasn't helped.
As a Industry there is lots one can do to prevent / reduce a DoS.
You can quarantine infected machines. You can install BCP 38 filters so traceback is more effective. You can ensure that fixed software images are always available. You can not orphan software just because it is old. You can auto update software.
You can take pro-active steps like surveying the your customers and informing them when they have a known vulnerable system.
For the root zone there is very little that is actually signed as most of the root zone is delegating NS records (not signed just their presence in the NSEC record is signed) and glue address records (not signed). If you can alter the root zone contents you can introduce new DS records matching DNSKEY records you control. These would then get signed and if you can direct your targets to this alternate version of the TLD it will be accepted as valid. This will only work until the zone signing key is rolled at which stage the DNSSEC validation chain will no longer work and you will need to go back and get the DS re-signed. Actually changing the root zone contents like this will almost certainly be caught as it is a highly examined zone. In particular people checking DS/DNSKEY pairs looking for errors so they can be fixed quickly. Now if you can get someone to sign a isolated DS RRset that is not in the root zone but is for a TLD then this could go undetected for longer but that is a much harder problem than just changing the root zone contents. That still only has a limited lifetime as the RRSIGs need to be refreshed.
The signing ceremony is where the DNSKEY RRset is re-signed to introduce / remove zone signing keys. The private part of the zone signing key has to be available on a day to day basis for the normal day to day changes in the root zone. That said the private part is still held in a HSM and the worst that can happen is that someone can get some data signed which can be used until the zone signing key is rolled.
The smart thing is to make all the cameras speed and red light camera. Prominently display where such camera are installed. Traffic will get used to this.
Where I live most of the red light cameras have been converted to safety cameras (red light + speed) and you will go through lots of intersections with them. This brings the speed down between cameras as well as reducing the number of accidents at intersections. Traffic actually travels within the speed limit instead of the +10 I often see on US roads.
And if sites actually added the SRV records specified in RFC 6186 Apple could avoid having to maintain a database of email to submission/pop3/imap/pop3s/imaps servers.
And at 3.3M they may as well just push it out rather than delaying it. A couple of checks will be more costly than just letting everyone download it straight away.
Actually we are getting Dr Who simultaneously with the UK if you are willing to get up at that time of the morning to watch. Or you can just record and time shift. Sunday 7:30pm is a replay of the morning's broadcast.
Not DANE the people, DANE (DNS based Authentication of Named Entities) http://tools.ietf.org/html/rfc... Mozilla are in a position to both publish TLSA record and authenticate the CERT.
Firstly ICANN had a black list of TLD labels that is wasn't going to allow anyone to apply for because they know they were likely to be in use.
If they looked at every "bad" TLD name that hit the root servers they could never add any new TLDs.
Having awarded contracts for TLD's they are try to minimise the impact on those labels that didn't make the black list or that they were unaware of.
Actually they do own and run one of the root servers. The company I work for owns and runs another of them. I submitted arguments, as a private individual, to not expand the root zone when this was being mooted. That all being said they are the legitimate party to decide what gets added to the root zone.
This isn't RFC 1535 all over again unless you are using partially qualified names where the end of the partially qualified name just happens to match one of the new TLDs. Partially qualified names have always been dangerous.
I just wish I had been able to convince Paul to break all existing use of partially qualified names back then by not appending search elements to any name with multiple labels. As much as foo.lab is convenient to type, foo.lab.example.net was safe as was foo + lab.example.net as a search list element.
They don't own you. However they are the authority for which names are added to the root zone. New TLD labels have always been possible and have been added from time to time.
The RBDMS vendors that squatted on a TLD were not rational actors. They knew or should have known that new TLDs could be added to the DNS at anytime. That new TLDS would be added to the DNS was published as part of the switch from a flat namespace to a hierarchical namespace. They failed to do due diligence. If they wanted a reserved name they could have requested one or heaven forbid registered one.
This is like vendors that squatted on 1.0.0.0 address space.
Firstly ICANN didn't just assert ownership of the root. They inherited it along with the rest of the IANA.
And the administrators gambled that no one else would ever register that tld. Sorry they just lost that bet.
The DNS is designed to allow everyone to have their own namespace. To do this you need to register the name so that it can be uniquely yours. If you can't register it, don't use it. Period.
As for those protocols they could have requested a reserved name. They just failed to do so. There have always been processes to get reserved names.
Multiple address, source address routing and multi path TCP will address lots of the reasons people want PI addresses today. IPv6 has enough addresses to make that mix of technologies a viable solution space. IPv4 is too resource constrained to make that a viable solution.
Until there is sufficient IPv6 penetration that continuing to run IPv4 becomes pointless. If you turn on IPv6 on home networks over half the incoming traffic will be IPv6 traffic. Globally IPv6 is 4-6% IP traffic depending upon where you measure it. IP has replaced many networking protocols in the past. IPv6 will replace IPv4. The writing is already on the wall.
Many networks today are IPv6 only internally with protocol translation to talk to the legacy IPv4 Internet.
Other are dual stack translated to IPv6 only then translated back to dual stack on the Internet.
With IPv4 you are only going to get less and less functionality now that many ISP's are getting to the stage of having to deploy CGNAT. As a home user having a publicly reachable address will become a thing of the past.
The average user will notice the lack of IPv6 when a CGN is put in the IPv4 path and things like port forwarding stop working. For some ISP's that is now. For others it is in the future. Until then you really shouldn't notice whether you are using IPv4 or IPv6 to reach another site or how you are reached. If you do notice then the ISP / OS vendor isn't doing their job properly.
Hopefully the ISP will take away the IPv6 knob and just deliver IPv6 to everyone in the near future. There aren't many IPv6 only reachable destinations yet but more are coming as more ISP's switch over to using CGN to deliver IPv4.
Apple II w/ 4K of memory would cost $5236.87 ($1298) in todays dollars. While this may be a lot less than a lot of computers at the time I wouldn't call it a cheap computer by any stretch of the imagination.
The way to defeat stupid laws like this is for everyone to actually send everything they intend to upload to the ratings board then to complain when you don't get a rating back in a timely manner to their representative.
It a combination of things. Sure you can photocopy a card if you can get access to it for long enough but
requiring a pin forces the customer to go to the card reader or the card reader to be brought to you. This
reduces the window when the card can be photocopied or the magstrip being fraudulently read. Add to
that the CC# is tagged as requiring a pin so you can't just put the details onto a blank and use it.
Online transactions still need the CCV.
No security is perfect.
The readers are very low powered so unless you actually put your wallet against the reader with multiple cards in it this isn't a issue. Just pull the card you want to use from the wallet. Yes, I have multiple contact less cards on me. A couple of credit cards and travel cards.
Are you saying that you would have caught the error if it was "return err;" instead of "goto fail;"?
Do you want to ban "return" next?
int err;
if ((err = PrepareHash(x,n)) != 0)
return err;
return err;
if ((err = CalculateHash(x,n)) != 0)
return err;
return CompleteHash(x,n);
In both cases there is code that is unreachable and a good dead code analysis will catch it.
Actually you often had a email account and logged in and read it using a command line interface and yes email was left in the mail box.
After that came POP and IMAP, both of which supported leaving email on the server. The main reason for down loading was the ridiculously small amounts of email storage space offered.
The entire premise that email over a certain number of days is abandoned was always false.
I just replaced a cable modem that was 10+ years old. I've got other equipment that is still going strong after 15 years. The only thing that was done, other than the occasional clean out of dust, was to replace a single fan. So yes, 20 years should be possible and if not the replacement costs of the powered equipment is a lot less than the full cost of installation. Replacing a CPE device will be less than $100 and will most probably support a faster connection speed. Replacing a line card will be similar on a per port basis. The fibre will last 20 years without a worry. The major problems with fibre will be back hoes and if the plastic sheath attracts animals.
The act is "Broadband Network Companies Act 2011" so you can't really blame it for the ageing infrastructure. If you want to blame anyone for the ageing infrastructure blame the ISP's that failed to invest in new technologies.
This two decade old paper shows Telstra's plans for FTTH in 1994 INT94b.PDF. Telstra failed to act on this for two decades. The introduction of the NBN is a reaction to that failure to act and a recognition that the costs are such that you needed a longer term outlook than next quarter's earnings. The NBN also got caught up in partisan politics which hasn't helped.
As a Industry there is lots one can do to prevent / reduce a DoS.
You can quarantine infected machines.
You can install BCP 38 filters so traceback is more effective.
You can ensure that fixed software images are always available.
You can not orphan software just because it is old.
You can auto update software.
You can take pro-active steps like surveying the your customers and informing them when they have a known vulnerable system.
For the root zone there is very little that is actually signed as most of the root zone is delegating NS records (not signed just their presence in the NSEC record is signed) and glue address records (not signed). If you can alter the root zone contents you can introduce new DS records matching DNSKEY records you control. These would then get signed and if you can direct your targets to this alternate version of the TLD it will be accepted as valid. This will only work until the zone signing key is rolled at which stage the DNSSEC validation chain will no longer work and you will need to go back and get the DS re-signed. Actually changing the root zone contents like this will almost certainly be caught as it is a highly examined zone. In particular people checking DS/DNSKEY pairs looking for errors so they can be fixed quickly. Now if you can get someone to sign a isolated DS RRset that is not in the root zone but is for a TLD then this could go undetected for longer but that is a much harder problem than just changing the root zone contents. That still only has a limited lifetime as the RRSIGs need to be refreshed.
The signing ceremony is where the DNSKEY RRset is re-signed to introduce / remove zone signing keys. The private part of the zone signing key has to be available on a day to day basis for the normal day to day changes in the root zone. That said the private part is still held in a HSM and the worst that can happen is that someone can get some data signed which can be used until the zone signing key is rolled.
And how do you know what to filter?
RPKI is about providing a trustworthy database that can be used to decide what to filter and what to permit.
The Australian Competition and Consumer Commission (ACCC).
$monthly * (throttled time / time in month) * 10.
The 10 times multiplier is a penalty. This is applied to all months for which the customer held a unlimited plan.
If AT&T don't have the data for when the plan was throttled the assumption should be that the plan was being throttled all the time.
It should also be a cheque not a credit.
The smart thing is to make all the cameras speed and red light camera. Prominently display where such camera are installed. Traffic will get used to this.
Where I live most of the red light cameras have been converted to safety cameras (red light + speed) and you will go through lots of intersections with them. This brings the speed down between cameras as well as reducing the number of accidents at intersections. Traffic actually travels within the speed limit instead of the +10 I often see on US roads.
And if sites actually added the SRV records specified in RFC 6186 Apple could avoid having to maintain a database of email to submission/pop3/imap/pop3s/imaps servers.
It's not like it is hard to add these records.
And at 3.3M they may as well just push it out rather than delaying it. A couple of checks will be more costly than just letting everyone download it straight away.
Actually we are getting Dr Who simultaneously with the UK if you are willing to get up at that time of the morning to watch. Or you can just record and time shift.
Sunday 7:30pm is a replay of the morning's broadcast.
Not DANE the people, DANE (DNS based Authentication of Named Entities) http://tools.ietf.org/html/rfc... Mozilla are in a position to both publish TLSA record and authenticate the CERT.
Firstly ICANN had a black list of TLD labels that is wasn't going to allow anyone to apply for because they know they were likely to be in use.
If they looked at every "bad" TLD name that hit the root servers they could never add any new TLDs.
Having awarded contracts for TLD's they are try to minimise the impact on those labels that didn't make the black list or that they were unaware of.
Actually they do own and run one of the root servers. The company I work for owns and runs another of them. I submitted arguments, as a private individual, to not expand the root zone when this was being mooted. That all being said they are the legitimate party to decide what gets added to the root zone.
This isn't RFC 1535 all over again unless you are using partially qualified names where the end of the partially qualified name just happens to match one of the new TLDs. Partially qualified names have always been dangerous.
I just wish I had been able to convince Paul to break all existing use of partially qualified names back then by not appending search elements to any name with multiple labels. As much as foo.lab is convenient to type, foo.lab.example.net was safe as was foo + lab.example.net as a search list element.
They don't own you. However they are the authority for which names are added to the root zone. New TLD labels have always been possible and have been added from time to time.
The RBDMS vendors that squatted on a TLD were not rational actors. They knew or should have known that new TLDs could be added to the DNS at anytime. That new TLDS would be added to the DNS was published as part of the switch from a flat namespace to a hierarchical namespace. They failed to do due diligence. If they wanted a reserved name they could have requested one or heaven forbid registered one.
This is like vendors that squatted on 1.0.0.0 address space.
Firstly ICANN didn't just assert ownership of the root. They inherited it along with the rest of the IANA.
And the administrators gambled that no one else would ever register that tld. Sorry they just lost that bet.
The DNS is designed to allow everyone to have their own namespace. To do this you need to register the name so that it can be uniquely yours. If you can't register it, don't use it. Period.
As for those protocols they could have requested a reserved name. They just failed to do so. There have always been processes to get reserved names.
Multiple address, source address routing and multi path TCP will address lots of the reasons people want PI addresses today. IPv6 has enough addresses to make that mix of technologies a viable solution space. IPv4 is too resource constrained to make that a viable solution.
Until there is sufficient IPv6 penetration that continuing to run IPv4 becomes pointless. If you turn on IPv6 on home networks over half the incoming traffic will be IPv6 traffic. Globally IPv6 is 4-6% IP traffic depending upon where you measure it. IP has replaced many networking protocols in the past. IPv6 will replace IPv4. The writing is already on the wall.
Many networks today are IPv6 only internally with protocol translation to talk to the legacy IPv4 Internet.
Other are dual stack translated to IPv6 only then translated back to dual stack on the Internet.
With IPv4 you are only going to get less and less functionality now that many ISP's are getting to the stage of having to deploy CGNAT. As a home user having a publicly reachable address will become a thing of the past.