The same applies to h.264 incidentally - free from royalties from known patent holders that are members of the MPEG-LA, but third parties that they don't yet know about may hold essential patents. Same is true of almost anything in computing these days, sadly.
the goal of each W3C Working Group is to produce a Recommendation that is not only technically sound, but that can be implemented according to the W3C Royalty-Free License requirements.
That page does go on to allow exceptions in some cases (such as overwhelming community consensus for a royalty-ed standard), but W3C does very strongly reccommend against royalty-requiring components of standards
Surely this has already been solved dozens of times before?
An example - use RSS and bittorrent. RSS feeds from content providers specify what to fetch (and could include any pertinent metadata like size, synopsis, etc) Retrieve the actual content via bittorrent - Throttle/pause transfers (or use QoS in the device) to handle the "idle time transfer" part of the deal. Heck, you might even relieve some of the bandwidth pressure this way by p2p downloading from devices on the same access system (cell, exchange, wifi point or whatever).
Another example - use a caching proxy (duh) and a published iCal calendar listing future things that may want to be cached.
Yeah I know content is terrified of the word "bittorrent" but great example of lawful use;) (though there's no reason the torrented files themselves couldn't be subject to DRM, evil as it is)
I wonder - if you don't actually consent to have something pushed onto your device but it does get pushed (and that will happen eventually) - how far does your implied license to the pushed content go? Given they basically gave it to you....
Indeed. I'm planning on rolling out the Magical Name Service shortly. It will make things so much easier when you don't have to specify any pesky name-IP mapping and things just magically go to the right IP for whatever you want, regardless of where it actually is today.
I don't dispute that there are other ways to do solve the same problems as NAT currently is used to solve.
I just argue that in certain situations (primarily SMB in my experience) NAT is one whole heck of a lot easier to set up, maintain and understand, to address those problems.
Port remapping is really handy. Users are, generally, not that great at retaining IT detail. My example of the mail server means that users have to remember just one DNS name.
Should you use independent addresses, you'll also need independent DNS records, so it becomes:
pop3.example.com
imap.example.com
smtp.example.com
webmail.example.com
etc.
I really really really don't trust random users to be that good at remembering stuff. using a single IP (and hence DNS record) to provide multiple services via port remapping is really really handy.
DHCPv6 has the same problem. In certain situations, one may not want systems getting configuration from DHCP. Ethernet is still (even with things like 802.1x etc) essentially a broadcast medium that anything can run anywhere on, and in some cases that makes autoconfig services a risk. So no, autoconfig+dhcp+dynamic DNS is still not a complete solution to the private addressing issue.
As addressed in my other post, neither is ULAs - in fact, ULA's close correspondence with private IPv4 ranges is itself an argument for NAT.
Yes NAT has resulted in some network evilness but it is not itself an evil technique.
ULA's aren't supposed to be routeable. That means you've got some of the problems of NAT (multiple address spaces) without its solutions (rewriting packet addresses)
Yes, you can assign multiple IPs per machine. You can do that with IPv4 too. It's an administrative nightmare generally. This will get especially bad if you've got a network with some services accessed by ULA and others by global address on Provider A's range, and yet more by global address on Provider B's range.
Oh, and one thing I forgot about NAT - it makes it REALLY easy to move publicly accessible services without interruption - just change a port forward and everyone automatically starts using the new service:)
NAT is just a really handy tool, for many reasons. It doesn't make sense to discard it for purely ideological reasons.
And lets face it - NAT is handy enough, and so entrenched, that if the IETF DOESN'T formally define a spec for it, we'll end up with vendors hacking up custom solutions in response to customer demand, which is definitely not a good thing. Let's just write a formal spec for NATv6 and let the greater internet decide whether it's a good thing or not.
He's right - NAT has useful functionality beyond just the "security" aspects.
The IPv6 internet model still only allows provider-independent addressing if you're a member of your regional NIC (with all the associated bits and pieces, like ASNs etc)
NAT is the only sane way to give your network provider independence under this system. If you're forced to renumber your network when changing ISPs, it's a real pain in the neck. Also - what if you want to do redundant internet connections? With IPv4 NAT you just set up the NATing firewall to have two connections with the same priority, enable stateful tracking, and away you go. That's flat out impossible with directly addressed IPv6 - every device would need two IP's (one for each provider subnet), and you'd need to manually configure each device to spit out some traffic with one source IP and other traffic with another source IP.
Additionally, NAT lets you do some useful stuff, like providing multiple services on multiple back-end machines via a single IP (which would of course correspond to a DNS record). For example, providing a "mail.example.com" address which provides POP3, IMAP, Webmail and SMTP submission service - POP3 and IMAP going to the mailstore machine, Webmail to a webserver and SMTP to an MX machine, without needing to configure slow port proxy services which lose valuable information (such as the source IP for connections)
As for IPv6 autoconfiguration, autoconfiguration doesn't deal with:
- Changing application settings dependent on IPv6 addresses
- Updating DNS records
- multiple internet providers/multiple subnets
- port remapping
Slashdot Mirror
because it's royalty-free for implementations of VP8 algorithms
It's free of royalties from Google, but third parties that Google doesn't yet know about may hold essential patents and join a patent pool that MPEG-LA is forming.
The same applies to h.264 incidentally - free from royalties from known patent holders that are members of the MPEG-LA, but third parties that they don't yet know about may hold essential patents. Same is true of almost anything in computing these days, sadly.
the goal of each W3C Working Group is to produce a Recommendation that is not only technically sound, but that can be implemented according to the W3C Royalty-Free License requirements.
That page does go on to allow exceptions in some cases (such as overwhelming community consensus for a royalty-ed standard), but W3C does very strongly reccommend against royalty-requiring components of standards
Beat me to it heh :)
Essentially this is a web content download issue.
;)
Surely this has already been solved dozens of times before?
An example - use RSS and bittorrent. RSS feeds from content providers specify what to fetch (and could include any pertinent metadata like size, synopsis, etc) Retrieve the actual content via bittorrent - Throttle/pause transfers (or use QoS in the device) to handle the "idle time transfer" part of the deal. Heck, you might even relieve some of the bandwidth pressure this way by p2p downloading from devices on the same access system (cell, exchange, wifi point or whatever).
Another example - use a caching proxy (duh) and a published iCal calendar listing future things that may want to be cached.
Yeah I know content is terrified of the word "bittorrent" but great example of lawful use
(though there's no reason the torrented files themselves couldn't be subject to DRM, evil as it is)
I wonder - if you don't actually consent to have something pushed onto your device but it does get pushed (and that will happen eventually) - how far does your implied license to the pushed content go? Given they basically gave it to you....
Indeed. I'm planning on rolling out the Magical Name Service shortly. It will make things so much easier when you don't have to specify any pesky name-IP mapping and things just magically go to the right IP for whatever you want, regardless of where it actually is today.
I don't dispute that there are other ways to do solve the same problems as NAT currently is used to solve.
I just argue that in certain situations (primarily SMB in my experience) NAT is one whole heck of a lot easier to set up, maintain and understand, to address those problems.
Port remapping is really handy. Users are, generally, not that great at retaining IT detail. My example of the mail server means that users have to remember just one DNS name.
Should you use independent addresses, you'll also need independent DNS records, so it becomes:
pop3.example.com
imap.example.com
smtp.example.com
webmail.example.com
etc.
I really really really don't trust random users to be that good at remembering stuff. using a single IP (and hence DNS record) to provide multiple services via port remapping is really really handy.
DHCPv6 has the same problem. In certain situations, one may not want systems getting configuration from DHCP. Ethernet is still (even with things like 802.1x etc) essentially a broadcast medium that anything can run anywhere on, and in some cases that makes autoconfig services a risk. So no, autoconfig+dhcp+dynamic DNS is still not a complete solution to the private addressing issue.
As addressed in my other post, neither is ULAs - in fact, ULA's close correspondence with private IPv4 ranges is itself an argument for NAT.
Yes NAT has resulted in some network evilness but it is not itself an evil technique.
ULA's aren't supposed to be routeable. That means you've got some of the problems of NAT (multiple address spaces) without its solutions (rewriting packet addresses)
:)
Yes, you can assign multiple IPs per machine. You can do that with IPv4 too. It's an administrative nightmare generally. This will get especially bad if you've got a network with some services accessed by ULA and others by global address on Provider A's range, and yet more by global address on Provider B's range.
Oh, and one thing I forgot about NAT - it makes it REALLY easy to move publicly accessible services without interruption - just change a port forward and everyone automatically starts using the new service
NAT is just a really handy tool, for many reasons. It doesn't make sense to discard it for purely ideological reasons.
And lets face it - NAT is handy enough, and so entrenched, that if the IETF DOESN'T formally define a spec for it, we'll end up with vendors hacking up custom solutions in response to customer demand, which is definitely not a good thing. Let's just write a formal spec for NATv6 and let the greater internet decide whether it's a good thing or not.
He's right - NAT has useful functionality beyond just the "security" aspects.
The IPv6 internet model still only allows provider-independent addressing if you're a member of your regional NIC (with all the associated bits and pieces, like ASNs etc)
NAT is the only sane way to give your network provider independence under this system. If you're forced to renumber your network when changing ISPs, it's a real pain in the neck. Also - what if you want to do redundant internet connections? With IPv4 NAT you just set up the NATing firewall to have two connections with the same priority, enable stateful tracking, and away you go. That's flat out impossible with directly addressed IPv6 - every device would need two IP's (one for each provider subnet), and you'd need to manually configure each device to spit out some traffic with one source IP and other traffic with another source IP.
Additionally, NAT lets you do some useful stuff, like providing multiple services on multiple back-end machines via a single IP (which would of course correspond to a DNS record). For example, providing a "mail.example.com" address which provides POP3, IMAP, Webmail and SMTP submission service - POP3 and IMAP going to the mailstore machine, Webmail to a webserver and SMTP to an MX machine, without needing to configure slow port proxy services which lose valuable information (such as the source IP for connections)
As for IPv6 autoconfiguration, autoconfiguration doesn't deal with:
- Changing application settings dependent on IPv6 addresses
- Updating DNS records
- multiple internet providers/multiple subnets
- port remapping
making it an incomplete solution in itself.