I just climbed it for the second time in late June. There was still plenty of snow and the LTE network was already mostly live on the Fujiyoshida side.
There is no train to the midpoint of climb. You can get pretty close to the mountain on a train but you need to take a bus or car or a long hike if you want to get to the fifth station.
While this sounds nice and neat, this isn't actually constitutional. The document permits the national government to provide incentives for states to implement federal policy but it can't compel them to give up their power to implement sales taxes where permitted by state constitutions.
It's far more likely the loan contract is written such that the lender would call the loan at some point during the decline in value and force him to liquidate the collateral and then some to satisfy the debt.
Now if the stock crashed in a short span (matter of days) then it's possible he could escape the debt because they couldn't force liquidation in time to recover any real value. For a company like Facebook that isn't entirely unthinkable but it is unlikely in the current climate.
I know you had plenty of help along the way but as a wise person once said - ultimately, all we have to offer to each other is ourselves. You definitely gave more than your share of time and energy to making plenty of people happier. You suffered fools with class and you should be proud of what you have done.
The NS glue records in the.com TLD are 172,800 seconds (2 days) but that has nothing to do with IPv6 day.
The actual IPv6 DNS records being advertised today are things like www.cisco.com (TTL 30 seconds), www.cisco.com (TTL 300 seconds), www.google.com (TTL 300 seconds) so backing them out isn't a big deal or something that needs a lot of lead time.
While it's not universally implemented, RA does work in many cases to advertise DNS resolvers to clients. Adoption of this is certainly going to increase because it is so unbelievably sweet in operation.
This is incorrect. This ruling went against Nagano Shoten's Maneki TV service which was targeted almost exclusively at a small number of Japanese living overseas - especially people who were doing the same thing by sticking a media PC at their Japanese apartment or parents house or whatnot and streaming it themselves.
Sony sells a device called location free TV that does the same thing except you set it up yourself with no service provider involved.
I wouldn't read too much into this ruling. If Sony is sued successfully then this would actually be news.
This is simply wrong. Please don't spout this anymore - you are spreading a myth.
There are about 40/8 blocks allocated to organizations.
Since 2004 we've used at least an average 10 blocks each year and I'm not including the rush in 2010 when 19 blocks were allocated.
If we could magically reclaim all 40 of these/8 blocks today it would buy us no more than 4 years. And remember - those organizations that lost their space would be eligible to immediate regain some percentage of their space based on their actual need.
So do we spend the next 4 years moving to IPv6 or do we spend 5 years in courts with 15-20 of the largest organizations on earth trying to reclaim space that was lawfully granted under the rules in place at the time? What is the better use of the effort that has to be expended either way?
Maybe if we went after all the legacy blocks we might be able to gain close to 10 years but at what cost - how can you possible make it happen quickly enough for it to make a difference?
Some of these organizations have already returned space and I don't doubt we'll see a couple more in the next year or two but it doesn't make a difference. We need to ask ourselves - do we solve this issue now or do we kick the can down the road? I'd rather be one of the ones who helps fix the mess we made.
Your smartphone might not need a public IP address but it certainly could benefit by having a unique IP address within the mobile operators network, right?
Do you know China Mobile has hundreds of millions of subscribers. Did you know even T-Mobile has 150 million subscribers globally? Any guess as to how large private IP space is? Hint - it isn't big enough for any of the major operators to supply a unique IP within their networks.
These large operators have had to choose between partitioning their subscribers which makes phone-to-phone applications a mess or using bogons (IPv4 space registered to other people!) which is what T-Mobile had been doing, or they can choose sanity, which for them includes IPv6 as it is large enough to handle these mobile networks address needs without breaking a sweat.
T-Mobile decided that IPv6 only with a NAT64 back to IPv4 is the right way to go for the future. It's doesn't solve all their issues but it's a pretty clean way for them to solve it with the minimum of cost and near maximum usability.
Other vendors are betting on IPv4 partitioning with IPv6 capability. If T-Mobile is successful with their approach it's likely IPv6 only on handsets will become the defacto standard. After all, why should your phone run two IP stacks when one can get the job done?
There is something to be said for wasting the summer and wasting the enthusiasm. Had they opened it from start it might have turned out differently.
Of course, it also might have turned into design by committee marathon flame war. We'll never know.
What is readily apparent to me after getting a seed up and running this week is that these guys are not the web devs to lead this effort. I predict another effort will pick up steam. Maybe GNU social, although that's in a pretty bad alpha state right now also.
The protocol is the key right now - the front end will sell this thing eventually but if the protocol sucks it will never go anywhere.
If you feel strongly about it run a NAT66 and be done with it. I'm sure there are people who will think this is worth the effort but I'm also certain they will be a minority.
As a side effect you'll likely still get end-to-end restored because the proposals I've read were one to one NATs for NAT66 since addresses aren't constrained there is no reason to use PAT so you'll probably need some kind of address scrambling (no different than NAT port selection).
>... the effect on reachability is almost exactly the same.
Not true. There are significant differences between NAT/PAT and stateful end-to-end.
To expose an internal service you need a NAT entry plus a firewall rule to allow the traffic versus only a rule with end-to-end.
If the protocol in use embeds IP addresses, then a special content mangling module has to be written to fix these embedded IP addresses while in transit. FTP is the canonical example of this insanity but there are plenty of these modules in existence that had to be written and the effect has been to force protocol designers to simplify because they want their traffic to pass through NAT/PAT setups. I think simple is better but who knows how things would have evolved differently had NAT taken such a large role in the IPv4 internet?
If two parties, both behind PAT, want to communicate directly then a firewall rule isn't enough to make this happen. You need a 3rd party or you have to switch to NAT on both ends. In and end-to-end setup if the rule is in place the packets can flow from either direction.
I think you get the concept but what are the end hosts? I don't understand that term? Is that the clients behind the NAT. The gateway address is supplied to them by IPv6 RA (router advertisments). The NAT64 is essentially advertising a/96 or greater subnet which is large enough to hold the entire IPv4 internet.
Here's the flow
web client -> DNS lookup for www.yahoo.com
DNS64 intercepts and instead of responding with A record 67.195.160.76 it responds with 2620:69::67.195.160.76 back to the client on the DNS port.
web client -> tries to connect to 2620:69::67.195.160.76, which is part of the block of space advertised by the NAT64 router.
NAT64 router receives the traffic and -> NAT64 translates 2620:69::67.195.160.76 back into 67.195.160.76 picking a random IPv4 port number on the way out. It records the session into a state table so it can handle returning packets.
NAT64 router -> sends the traffic to www.yahoo.com 67.195.160.76
yahoo -> responds on IPv4 and the NAT64 looks up the session and returns it to the client that requested it.
When you get right down to it, this is just a slightly different kind of regular old NAT, same as any with the same issues as IPv4 NAT has. And just like IPv4 NATs run into trouble when addresses are embedded in the traffic itself, NAT64/DNS64 will have to account for fixing that breakage and this is done by content inspection. And just like IPv4 NAT has to make special effort to connect 2 NAT'ed clients, this solution would have to use the same hole punching techniques to allow connections.
Assuming the content inspection work is done, it should be possible to run an IPv6 only network with connectivity to IPv4 via NAT. Whether or not this is desirable is questionable but I have no doubt some geeks will do this at home just because it can be done.
Slashdot Mirror
Yes, it's in RHEL7 release candidate (GA should ship next month)
I just climbed it for the second time in late June. There was still plenty of snow and the LTE network was already mostly live on the Fujiyoshida side.
There is no train to the midpoint of climb. You can get pretty close to the mountain on a train but you need to take a bus or car or a long hike if you want to get to the fifth station.
He should expand into seedboxes
Using the Coinstar experience, the answer to this question is something under 90.2 cents but the data is clouded by nickels, dimes, and quarters...
While this sounds nice and neat, this isn't actually constitutional. The document permits the national government to provide incentives for states to implement federal policy but it can't compel them to give up their power to implement sales taxes where permitted by state constitutions.
It's far more likely the loan contract is written such that the lender would call the loan at some point during the decline in value and force him to liquidate the collateral and then some to satisfy the debt.
Now if the stock crashed in a short span (matter of days) then it's possible he could escape the debt because they couldn't force liquidation in time to recover any real value. For a company like Facebook that isn't entirely unthinkable but it is unlikely in the current climate.
Heads up - If you hold down the comma key for a couple of seconds you'll get an apostrophe.
This shortcut has been in there from the beginning on the iPad.
I've got a blackberry :-(
Rob,
Thank you for creating Slashdot
I know you had plenty of help along the way but as a wise person once said - ultimately, all we have to offer to each other is ourselves. You definitely gave more than your share of time and energy to making plenty of people happier. You suffered fools with class and you should be proud of what you have done.
Good luck
Malaysia and Japan also fingerprint visitors
The NS glue records in the .com TLD are 172,800 seconds (2 days) but that has nothing to do with IPv6 day.
The actual IPv6 DNS records being advertised today are things like www.cisco.com (TTL 30 seconds), www.cisco.com (TTL 300 seconds), www.google.com (TTL 300 seconds) so backing them out isn't a big deal or something that needs a lot of lead time.
January 6 through April 14. CentOS patches for version 5 were nonexistent.
Take a look at the RHEL watch list for the same period and compare.
https://www.redhat.com/archives/enterprise-watch-list/
There has been some strong criticism of the CentOS team recently and frankly, some of it is deserved.
It was recorded so you'll be able to catch it later.
You didn't miss much. Extremely boring speeches by some not very talented speakers.
While it's not universally implemented, RA does work in many cases to advertise DNS resolvers to clients. Adoption of this is certainly going to increase because it is so unbelievably sweet in operation.
Somebody mod this guy up - he is exactly correct about this whole issue.
This is incorrect. This ruling went against Nagano Shoten's Maneki TV service which was targeted almost exclusively at a small number of Japanese living overseas - especially people who were doing the same thing by sticking a media PC at their Japanese apartment or parents house or whatnot and streaming it themselves.
Sony sells a device called location free TV that does the same thing except you set it up yourself with no service provider involved.
I wouldn't read too much into this ruling. If Sony is sued successfully then this would actually be news.
This is simply wrong. Please don't spout this anymore - you are spreading a myth.
There are about 40 /8 blocks allocated to organizations.
Since 2004 we've used at least an average 10 blocks each year and I'm not including the rush in 2010 when 19 blocks were allocated.
If we could magically reclaim all 40 of these /8 blocks today it would buy us no more than 4 years. And remember - those organizations that lost their space would be eligible to immediate regain some percentage of their space based on their actual need.
So do we spend the next 4 years moving to IPv6 or do we spend 5 years in courts with 15-20 of the largest organizations on earth trying to reclaim space that was lawfully granted under the rules in place at the time? What is the better use of the effort that has to be expended either way?
Maybe if we went after all the legacy blocks we might be able to gain close to 10 years but at what cost - how can you possible make it happen quickly enough for it to make a difference?
Some of these organizations have already returned space and I don't doubt we'll see a couple more in the next year or two but it doesn't make a difference. We need to ask ourselves - do we solve this issue now or do we kick the can down the road? I'd rather be one of the ones who helps fix the mess we made.
Your smartphone might not need a public IP address but it certainly could benefit by having a unique IP address within the mobile operators network, right?
Do you know China Mobile has hundreds of millions of subscribers. Did you know even T-Mobile has 150 million subscribers globally? Any guess as to how large private IP space is? Hint - it isn't big enough for any of the major operators to supply a unique IP within their networks.
These large operators have had to choose between partitioning their subscribers which makes phone-to-phone applications a mess or using bogons (IPv4 space registered to other people!) which is what T-Mobile had been doing, or they can choose sanity, which for them includes IPv6 as it is large enough to handle these mobile networks address needs without breaking a sweat.
T-Mobile decided that IPv6 only with a NAT64 back to IPv4 is the right way to go for the future. It's doesn't solve all their issues but it's a pretty clean way for them to solve it with the minimum of cost and near maximum usability.
Other vendors are betting on IPv4 partitioning with IPv6 capability. If T-Mobile is successful with their approach it's likely IPv6 only on handsets will become the defacto standard. After all, why should your phone run two IP stacks when one can get the job done?
Dual stack works but is has failed in the sense that it can't be the singular solution during the transition from IPv4 to IPv6.
Computer
There is something to be said for wasting the summer and wasting the enthusiasm. Had they opened it from start it might have turned out differently.
Of course, it also might have turned into design by committee marathon flame war. We'll never know.
What is readily apparent to me after getting a seed up and running this week is that these guys are not the web devs to lead this effort. I predict another effort will pick up steam. Maybe GNU social, although that's in a pretty bad alpha state right now also.
The protocol is the key right now - the front end will sell this thing eventually but if the protocol sucks it will never go anywhere.
If you feel strongly about it run a NAT66 and be done with it. I'm sure there are people who will think this is worth the effort but I'm also certain they will be a minority.
As a side effect you'll likely still get end-to-end restored because the proposals I've read were one to one NATs for NAT66 since addresses aren't constrained there is no reason to use PAT so you'll probably need some kind of address scrambling (no different than NAT port selection).
> ... the effect on reachability is almost exactly the same.
Not true. There are significant differences between NAT/PAT and stateful end-to-end.
To expose an internal service you need a NAT entry plus a firewall rule to allow the traffic versus only a rule with end-to-end.
If the protocol in use embeds IP addresses, then a special content mangling module has to be written to fix these embedded IP addresses while in transit. FTP is the canonical example of this insanity but there are plenty of these modules in existence that had to be written and the effect has been to force protocol designers to simplify because they want their traffic to pass through NAT/PAT setups. I think simple is better but who knows how things would have evolved differently had NAT taken such a large role in the IPv4 internet?
If two parties, both behind PAT, want to communicate directly then a firewall rule isn't enough to make this happen. You need a 3rd party or you have to switch to NAT on both ends. In and end-to-end setup if the rule is in place the packets can flow from either direction.
T-Mobile is using IPv4 BOGONS (using IPs which are registered to others or will be registered to others).
Which is why they are rapidly moving to IPv6 with access to IPv4 via NAT64/DNS64.
I think you get the concept but what are the end hosts? I don't understand that term? Is that the clients behind the NAT. The gateway address is supplied to them by IPv6 RA (router advertisments). The NAT64 is essentially advertising a /96 or greater subnet which is large enough to hold the entire IPv4 internet.
Here's the flow
web client -> DNS lookup for www.yahoo.com
DNS64 intercepts and instead of responding with A record 67.195.160.76 it responds with 2620:69::67.195.160.76 back to the client on the DNS port.
web client -> tries to connect to 2620:69::67.195.160.76, which is part of the block of space advertised by the NAT64 router.
NAT64 router receives the traffic and -> NAT64 translates 2620:69::67.195.160.76 back into 67.195.160.76 picking a random IPv4 port number on the way out. It records the session into a state table so it can handle returning packets.
NAT64 router -> sends the traffic to www.yahoo.com 67.195.160.76
yahoo -> responds on IPv4 and the NAT64 looks up the session and returns it to the client that requested it.
When you get right down to it, this is just a slightly different kind of regular old NAT, same as any with the same issues as IPv4 NAT has. And just like IPv4 NATs run into trouble when addresses are embedded in the traffic itself, NAT64/DNS64 will have to account for fixing that breakage and this is done by content inspection. And just like IPv4 NAT has to make special effort to connect 2 NAT'ed clients, this solution would have to use the same hole punching techniques to allow connections.
Assuming the content inspection work is done, it should be possible to run an IPv6 only network with connectivity to IPv4 via NAT. Whether or not this is desirable is questionable but I have no doubt some geeks will do this at home just because it can be done.