Re:IPv6 is MUCH more than a replacement for IPv4
on
The State of IPv6
·
· Score: 1
First, what the ISP says in its service agreement and what they let you get away with are two different things. My ISP sells me a static IP address so that my computers can accept incoming traffic and then tries to say that I can't run servers. There's something of a contradiction there.
What they generally mean when they say this is that they don't want you using a residential account to provide commercial service, and they don't want you eating up arbitrary amounts of bandwidth even for noncommercial use. So if you make porn or mp3s or whatever available for download and your site gets popular, they've got an excuse to hold you in violation of the agreement. But that doesn't mean that they're going to filter the traffic that would go to your toaster.
Eventually they'll find a better way to distinguish "bad servers" from "good servers". Or maybe they'll just limit your bandwidth if you eat too much of it.
somebody else beat me to my own post...
on
The State of IPv6
·
· Score: 2, Funny
Several of the comments seem to result from what I think of as "dubious" assumptions about IPv6. I got tired of listing these every time the IPv6 migration discussion came up, so now I maintain that list in a web page:
Dubious Assumptions About IPv6
Of course, a huge number of people actually use Rendezvouz to do useful things on their networks, which makes your "failure to solve the problem" complaint seem rather meaningless.
You're taking my comment out of context. Yes, Rendezvous can be useful, for specific apps in specific contexts. But it also causes lots of problems when used by apps in general. Apple has tried to promote it as a general-purpose solution for name lookup on local networks, and Rendezvous is really poorly designed for that.
Criticizing Apple for shipping product when the IETF is in revision twenty-seven of an attempt to simply explain how Apple's working code is functioning is a perfect example of why the IETF has slipped further and further into irrelevance.
Wby -- because IETF is trying to clean up the colossal mess that Apple has created? The reason that 27 revisions have been needed is that mDNS started out with such a naive approach - it's fundamentally a far more difficult problem than Apple ever anticipated.
The fact that namedroppers --- the IETF DNS discussion group --- is intensely politicized (a problem that Keith Moore is an intimate part of) just plays into that.
Check the archive. I've made very few posts to the namedroppers list.
Name lookup is a critical service used by almost every application, not something that can be tweaked arbitrarily and without due care.
if you read rfc2782 you will see that SRV isn't intended to be retroactively applied to all applications - because it would break compatibility with apps that expected to use default port numbers. SRV should only be used by applications which are explicitly specified to use it, and HTTP/web browsing hasn't been specified to use SRV.
to really fix web browsing it should use NAPTR records in addition to SRV records - that would allow arbitrary mappings from from any URI type to any suitable access protocol, including URNs that don't have locations embedded in them.
mDNS is a huge mess, mostly because Apple started deploying the thing without realizing that you'd have different hosts on the same network, some using mDNS and some using DNS (since not all hosts that are connected will see the same peers) and without bothering to figure out how to keep mDNS and DNS in sync.
the last time I looked the problem still wasn't solved. but the draft is in revision 27 after being taken on by an IETF working group, and still isn't done yet, which should tell you something about how ready it was for prime time when Apple shipped it.
the rest of Rendezvous (v4 linklocal addressing and DNS resource discovery) is also a huge mess, but that's another topic.
It's my understanding that ILS picks up information from a beacon in front of the plane, so why should it even be susceptible to radio signals from something behind it?
Part of the ILS signal (the localizer) is sometimes used from behind in navigation - for instance when flying a "back course" approach or when flying a missed approach course that needs precise guidance along the runway heading. Also, ILS and VOR navigation use some of the same frequences, the same receivers, and the same antennas - and VOR naviation requires an omnidirectional antenna. (And FWIW the NAV/GS antennas are typically in the tail, so passengers are still "in front' of them.)
Also, the radiation doesn't have to be picked up by the antenna to cause interference if the signal source is close enough. (almost certainly not from the ground, but from inside the plane where the energy can be picked up by the plane's wiring) And the interference doesn't have to be on the primary navigational frequency - it can be any frequency that affects the internal operation of navigational radios - or any of the aircraft's electronics.
Modern aircraft navigational equipment is designed to be reasonably immune to interference, and most existing navigational equipment is not affected by cell phones or other portable electronic devices. However it's very hard to be sure that no kind of interference is possible, especially after the equipment is installed in an aircraft.
Also, the age and capabilities of aircraft vary considerably across the fleet, and it would be extremely expensive to require them all to be retro-fit - especially when there is no good test that can reliably say "this setup doesn't have a problem with interference" and the vast majority of aircraft don't actually seem to have this problem. There are few cases where interference has actually been observed to cause problems, and those problems are fixed as they are identified. Turning PEDs off is an inexpensive way to get an added margin of safety for the problems that haven't been identified yet.
I've always wondered why electronic equipment on planes was so much more sensitive then the regular stuff we have down on earth.
When your cell phone drops a call, how do you know that the problem isn't some nearby noise-emitting device? You don't. But chances are you've never had a dropped cell call cause a life-threatening situation - it's just an annoyance, and we're used to having cell phones not be that reliable.
Putting the equipment on an aircraft doesn't make it any more sensitive than any other kind of electronic equipment. However navigational equipment on aircraft is trusted with human lives. Category 3 ILS approaches have to guide the aircraft to a landing in zero visibility with a tolerance of a few feet in any direction. Disruption of that system would be very, very bad.
If you trusted electronic navigational equipment to drive your car down the highway through dense fog and to keep from hitting other cars, you'd be worried about the sensitivity of that equipment too.
The RFC2554 (SASL) authentication is somewhat flawed. A key point of SMTP is that the Email transmission can be differentiated between originators and forwarders and the reception can be differentiated between post-offices and recipients.
I'm not sure what you're trying to say here.
RFC2554 seems to get to a lot of hand waving when we get to the 'on-behalf-of'. That is, my ISP's SMTP gateway can't easily pass on that I was authenticated to the recipients POP server.
Nor is there any reason that the next hop should take your ISP's word for that. However I agree that we need a better way to convey to the recipient the fact that the message was authenticated by the originator - e.g. we need for the ISP to sign a hash of the message and include some sort of tracable identity of the originator. But we don't need to entirely change the mail protocol in order to do this.
As for handling multiple CAs, this is akin to a routing problem. I have a set of key certs from CAs {A,B,C,D} and you trust key certs from {D,E,F,G} - ok we can agree on D. However if there is no coincidental certification authority, then we need to be able to find trust intermediaries by a process akin to routing.
Trust isn't transitive anyway, so it's highly unlikely that such intermediaries would exist.
To reject spam, what I need to know is that the originator has been authenticated. Spam is rarely sent by people using correct Email addresses because they can be filtered.
What you need to know is not that the sender's email address is correct (well, it would be nice to know that the email address had not been forged, but that's a separate issue) but that the email can be reliably and efficiently traced to the party who sent it, and that that party will be held responsible and suffer substantial penalty for abusing email.
As for binaries, the support for RFC3030 is problematic and it only applies to the body (when it is sent and accepted - the RFC has only existed for three years). Also the character set support is limited because binary encapsulation applies to the body, not the header. It gets really fun trying to interpret Cyrillic subject lines, when it isn't the natice character set of your system.
Headers are required to be in ASCII (RFC 2047 encoding if necessary) both for compatibility with existing parsers and because there is a need to indicate the character set in use (and it won't necessarily be the same for every field in the header). That is a feature of RFC 822/2822 and MIME, not a limitation of SMTP binary transmission. But RFC 2047 allows use of any charset that is usable in the message body. The real trouble happens when someone violates the spec and sends unencoded text with characters outside the ASCII repertoire - then you have to use heuristics (or ISO2022 encoding if you're lucky) to guess which charset it is. Again, this isn't a problem with SMTP - the same problem would exist for any mail transmission protocol carrying MIME messages. If you went to a new mail format and forced everyone to use UTF-8, you could dispense with that problem (at a huge cost). Last I knew there were still large groups who were not happy with the ISO 10646/Unicode repertoire.
The problem is with hierarchical systems. Compromise the CA and everything else goes out of the window. With distributed trust systems such as pgp/gpg, a person's key may be certified by multiple CAs.
Yes, you can and should have the ability to trust multiple CAs, and in fact I was assuming that this would be the case. My point was that it is extremely difficult to deploy this on a sufficiently wide scale that any legitimate party can send mail to an arbitrary recipient.
I disagree with you about SMTP, first the authentication sucks, secondly the need to encode binary data is a major shortcoming.
SMTP authentication uses SASL so it's very extensible. It can support public key authentication via either GSSAPI or TLS client certificates (using AUTH EXTERNAL). As for transmission of binary data, that's been standardized for several years; see RFC 3030.
SMTP is not the problem
on
Replacing SMTP?
·
· Score: 2, Informative
The problem is that building trust networks is really difficult, and all the ways that make it look easy actually end up making some small set of concerns (i.e. the certificate authorities) very powerful, and thus, dangerous.
SMTP already has authentication, and anyone who operates an SMTP server is free to accept or not accept mail from whomever he wants. You don't need a new protocol to require mail to be authenticated. If you can solve the trust problem, you can implement a trusted mail solution more quickly and easily with SMTP than by requiring deployment of an entirely new protocol.
NAT breaks nothing except applications stupid enough to put their local IP inside the data they send.
As it turns out, there are good reasons to do precisely that in distributed applications. DNS is neither fast nor reliable enough to serve as a substitute for IP addresses in all situations. Furthermore the Internet was designed to have a global address space, in fact the Internet Protocol depends on this working because IP routers make routing decisions independently. Networks using private address space cannot exchange routing information with the Internet or with other networks, they have to NAT everything at their borders.
What you are calling IP Masquerading is generally called NAPT - Network Address and Port Translation - in the RFCs. NAPT generally implies that the network is not able to accept unsolicited traffic to arbitrary hosts (because there's no way for the NAPT to know where the traffic goes) but in practice this limitation applies to most NATs even if they are not configured to do NAPT.
I'm amused that you think my complaints are invalid when they are breaking fundamental design features of the Internet Protocol and they are preventing the ability of many useful applications to work. Oh well, these days vendors can get away with breaking whatever they want, and not suffer any pain from doing so.
I would assume that a large amount (majority?) of NAT users do not have any of these problems.
I don't think that's a valid assumption. But it's probably more accurate to say that NAT users don't realize that the fact that they have NATs installed means that some useful applications are not available to them - like standards-based Internet telephony (just to name one example). NATs are so widely deployed that they've killed the potential market for some very useful apps that happen to need the ability to send unsolicited traffic to hosts. If you had a plain firewall you could selectively enable that particular app; but with a NAT (at least, a NAT that multiplexes several internal addresses onto one external one) you can't do that - the NAT actually has to have code that knows about your app protocol in order to make this work, and sometimes that's simply not feasible.
As for the shortage of IPv4 address space, it's real. It's just that the shortage you are seeing is caused by the real shortage. If the restrictions on address allocation were not in place, China alone would consume the remaining addresses tomorrow.
IMHO nothing too bad with IPv4 and NAT... if it was implemted properly.
that's because you haven't tried to write distributed apps that work across NATs...
here is a list of NAT problems that I cons'ed up because I got tired of trying to explain this over and over.
there's no way to fix NAT without having a global address space, and that's precisely what NAT takes away. various groups have tried in vain to fix NAT (RSIP, MIDCOM, HIP) and all of the solutions are of limited applicability.
The real blame for IPv6, DNSSEC and IPSEC being nowhere is the IETF. And before ACs come back telling me that IPSEC is widely used for VPNs, yes I know, but a VPN is not what IPSEC is designed for. IPSEC was intended to be INTERNET security.
IPsec may have been intended for Internet security, but it suffers from several assumptions that were obsolete years ago - namely that hosts are meaningful as security principals, and IP addresses are good names for hosts. HIP goes a long way to alleviate some of those problems. The other thing that IPsec needs is a good API to make it accessible to applications, and in particular to allow applications to set their own authentication credentials and use their own security policies.
But I'd agree that IPsec hasn't turned out to be a boon for IPv6 - if anything it has delayed IPv6 deployment without adding useful functionality. Hindsight is perfect, of course.
As for your remarks about IETF, personally I don't find namedropping (either of those who are contributing to IETF or those who aren't) makes very useful criticism.
IPv6 is irrelevant for this discussion. you don't necessarily have to upgrade your router to route IPv6 (especially if it supports MPLS). and if you do decide to upgrade to IPv6 it will be because of customer demand for it and/or the shortage of IPv4 addresses not because of some Cisco conspiracy.
for that matter if you install the hardware and software necessary to support LE surveillance then it won't be because Cisco forced you to do so but because the government forced you to do so. otherwise, you wouldn't spend the extra money.
it's just a draft by one guy. anybody can submit a draft. it doesn't mean anything in terms of IETF approval. however since it purports it might eventually get published as an Informational document (not a standard).
if you think this is a transparent attempt to get IETF to appear to endorse a heinous activity (as I do) then you might want to write the IESG and/or the RFC Editor (as I intend to) and object to such publication. in order to avoid flooding their normal mailboxes, perhaps someone would like to set up a mailing list?
when governments think they have the right to kill thousands of people with scant justification, the last thing we need is to help them standardize on surveillance technologies.
As other people have pointed out, this is not an IETF working group - it's an IRTF research group, and as such its purpose is to try to understand the problem and the solution space rather than to propose a concrete solution for standardization. Many of the folks in the group don't seem to have figured this out yet either. As a result there have been a number of naive proposals for how to solve the problem, along with a huge number of arguments of the form "your proposal is broken in X way".
But the group just got started a few days ago, and is only barely starting to move in any particular direction. Trying to make any predictions about the group's eventual output from what has been discussed so far is probably not a useful exercise.
I would say in the air you have an infinite number of possible paths, on ground you only have very expensive roads.
an infinite number of possible paths actually provides more opportunities for paths to cross. that and just because there are an infinite number of possible paths does not mean that everyone will choose a random path. most pilots with gps would prefer to fly a straight line between source and destination, which means that for popular source,destination pairs there are only a few paths. in some places, and at some times, paths are also constrained by weather and terrain.
I'm almost positive that a consumer vehicle in the range of $10k-$30k is capable of surviving a 10 story fall without any bodily harm, in fact the driver might be better off due to the delay before the "big crash".
making a vehicle that can survive the fall and still be light enough to fly cheaply is a serious engineering challenge. protecting the human body from such a fall is even harder. our skeletons are much better at dealing with horizontal impact than vertical impact. parachutes are probably the best bet, but they do add to the cost.
There already exist proximity avionics that will alert the pilots of two planes flying close or in an intercept course that they need to watch out for another aircraft.
indeed, though such devices are not cheap. perhaps economies of scale would drive the costs down, though the transponders and TCAS would also have to get a lot more sophisticated than they are now.
also note that being able to survive the occasional screwup by ATC, pilot deviating from a clearance, or failure of a pilot to see and avoid another aircraft in visual conditions - is not anything like the same thing as being able to avoid hundreds of thousands of aircraft piloted by fellow commuters - everyone trying to get home from work.
air traffic control is probably the biggest problem. the ATC system is already overtaxed in busy areas and part of how they cope is by discouraging general aviation. it's certainly technically feasible for personal aircraft to be reliable, affordable, and about as easy to fly as it is to drive a car IF you can get enough people to use them. but if you get enough people to use them you have a traffic management problem far worse than anything we've ever seen on the ground.
face it, one reason we want to travel by air is to avoid traffic jams - but as soon as we put everyone in the air we need to find ways to keep everyone from hitting each other, and to do that we end up imposing the same kinds of constraints we have on the ground. at least on the ground we can often survive collisions between vehicles.
actually, numbers are great. they are terse, they work on any keyboard in the world (including telephone keyboards), and they are language-independent. and when you think about it, phone numbers really aren't much less mnemonic than the local-part of a typical big-ISP email address. of course, nobody's suggesting that we use numbers instead of email addresses or URLs, but addresses that consist of nothing but digits are in fact quite useful.
and anyway, enum is only half of the picture - there's also a proposal for mapping URLs to other information from the rescap working group. The basic idea is that an identifier should not be inherently tied to one single kind of resource - given either a phone number or a URL (and the latter includes email addresses), you should be able to find out additional information about that resource if the owner of that number/URL wants to provide it. phone number to web page? easy. email address to phone number? sure, if I want to provide it. or maybe you have my voice # and want to send me email. again, no problem.
Slashdot Mirror
First, what the ISP says in its service agreement and what they let you get away with are two different things. My ISP sells me a static IP address so that my computers can accept incoming traffic and then tries to say that I can't run servers. There's something of a contradiction there.
What they generally mean when they say this is that they don't want you using a residential account to provide commercial service, and they don't want you eating up arbitrary amounts of bandwidth even for noncommercial use. So if you make porn or mp3s or whatever available for download and your site gets popular, they've got an excuse to hold you in violation of the agreement. But that doesn't mean that they're going to filter the traffic that would go to your toaster.
Eventually they'll find a better way to distinguish "bad servers" from "good servers". Or maybe they'll just limit your bandwidth if you eat too much of it.
guess I need to check /. more often...
Several of the comments seem to result from what I think of as "dubious" assumptions about IPv6. I got tired of listing these every time the IPv6 migration discussion came up, so now I maintain that list in a web page: Dubious Assumptions About IPv6
Of course, a huge number of people actually use Rendezvouz to do useful things on their networks, which makes your "failure to solve the problem" complaint seem rather meaningless.
You're taking my comment out of context. Yes, Rendezvous can be useful, for specific apps in specific contexts. But it also causes lots of problems when used by apps in general. Apple has tried to promote it as a general-purpose solution for name lookup on local networks, and Rendezvous is really poorly designed for that.
Criticizing Apple for shipping product when the IETF is in revision twenty-seven of an attempt to simply explain how Apple's working code is functioning is a perfect example of why the IETF has slipped further and further into irrelevance.
Wby -- because IETF is trying to clean up the colossal mess that Apple has created? The reason that 27 revisions have been needed is that mDNS started out with such a naive approach - it's fundamentally a far more difficult problem than Apple ever anticipated.
The fact that namedroppers --- the IETF DNS discussion group --- is intensely politicized (a problem that Keith Moore is an intimate part of) just plays into that.
Check the archive. I've made very few posts to the namedroppers list.
Name lookup is a critical service used by almost every application, not something that can be tweaked arbitrarily and without due care.
if you read rfc2782 you will see that SRV isn't intended to be retroactively applied to all applications - because it would break compatibility with apps that expected to use default port numbers. SRV should only be used by applications which are explicitly specified to use it, and HTTP/web browsing hasn't been specified to use SRV.
to really fix web browsing it should use NAPTR records in addition to SRV records - that would allow arbitrary mappings from from any URI type to any suitable access protocol, including URNs that don't have locations embedded in them.
mDNS is a huge mess, mostly because Apple started deploying the thing without realizing that you'd have different hosts on the same network, some using mDNS and some using DNS (since not all hosts that are connected will see the same peers) and without bothering to figure out how to keep mDNS and DNS in sync.
the last time I looked the problem still wasn't solved. but the draft is in revision 27 after being taken on by an IETF working group, and still isn't done yet, which should tell you something about how ready it was for prime time when Apple shipped it.
the rest of Rendezvous (v4 linklocal addressing and DNS resource discovery) is also a huge mess, but that's another topic.
It's my understanding that ILS picks up information from a beacon in front of the plane, so why should it even be susceptible to radio signals from something behind it?
Part of the ILS signal (the localizer) is sometimes used from behind in navigation - for instance when flying a "back course" approach or when flying a missed approach course that needs precise guidance along the runway heading. Also, ILS and VOR navigation use some of the same frequences, the same receivers, and the same antennas - and VOR naviation requires an omnidirectional antenna. (And FWIW the NAV/GS antennas are typically in the tail, so passengers are still "in front' of them.)
Also, the radiation doesn't have to be picked up by the antenna to cause interference if the signal source is close enough. (almost certainly not from the ground, but from inside the plane where the energy can be picked up by the plane's wiring) And the interference doesn't have to be on the primary navigational frequency - it can be any frequency that affects the internal operation of
navigational radios - or any of the aircraft's electronics.
Modern aircraft navigational equipment is designed to be reasonably immune to interference, and most existing navigational equipment is not affected by cell phones or other portable electronic devices. However it's very hard to be sure that no kind of interference is possible, especially after the equipment is installed in an aircraft.
Also, the age and capabilities of aircraft vary considerably across the fleet, and it would be extremely expensive to require them all to be retro-fit - especially when there is no good test that can reliably say "this setup doesn't have a problem with interference" and the vast majority of aircraft don't actually seem to have this problem. There are few cases where interference has actually been observed to cause problems, and those problems are fixed as they are identified. Turning PEDs off is an inexpensive way to get an added margin of safety for the problems that haven't been identified yet.
I've always wondered why electronic equipment on planes was so much more sensitive then the regular stuff we have down on earth.
When your cell phone drops a call, how do you know that the problem isn't some nearby noise-emitting device? You don't. But chances are you've never had a dropped cell call cause a life-threatening situation - it's just an annoyance, and we're used to having cell phones not be that reliable.
Putting the equipment on an aircraft doesn't make it any more sensitive than any other kind of electronic equipment. However navigational equipment on aircraft is trusted with human lives. Category 3 ILS approaches have to guide the aircraft to a landing in zero visibility with a tolerance of a few feet in any direction. Disruption of that system would be very, very bad.
If you trusted electronic navigational equipment to drive your car down the highway through dense fog and to keep from hitting other cars, you'd be worried about the sensitivity of that equipment too.
I'm not sure what you're trying to say here.
RFC2554 seems to get to a lot of hand waving when we get to the 'on-behalf-of'. That is, my ISP's SMTP gateway can't easily pass on that I was authenticated to the recipients POP server.
Nor is there any reason that the next hop should take your ISP's word for that. However I agree that we need a better way to convey to the recipient the fact that the message was authenticated by the originator - e.g. we need for the ISP to sign a hash of the message and include some sort of tracable identity of the originator. But we don't need to entirely change the mail protocol in order to do this.
As for handling multiple CAs, this is akin to a routing problem. I have a set of key certs from CAs {A,B,C,D} and you trust key certs from {D,E,F,G} - ok we can agree on D. However if there is no coincidental certification authority, then we need to be able to find trust intermediaries by a process akin to routing.
Trust isn't transitive anyway, so it's highly unlikely that such intermediaries would exist.
To reject spam, what I need to know is that the originator has been authenticated. Spam is rarely sent by people using correct Email addresses because they can be filtered.
What you need to know is not that the sender's email address is correct (well, it would be nice to know that the email address had not been forged, but that's a separate issue) but that the email can be reliably and efficiently traced to the party who sent it, and that that party will be held responsible and suffer substantial penalty for abusing email.
As for binaries, the support for RFC3030 is problematic and it only applies to the body (when it is sent and accepted - the RFC has only existed for three years). Also the character set support is limited because binary encapsulation applies to the body, not the header. It gets really fun trying to interpret Cyrillic subject lines, when it isn't the natice character set of your system.
Headers are required to be in ASCII (RFC 2047 encoding if necessary) both for compatibility with existing parsers and because there is a need to indicate the character set in use (and it won't necessarily be the same for every field in the header). That is a feature of RFC 822/2822 and MIME, not a limitation of SMTP binary transmission. But RFC 2047 allows use of any charset that is usable in the message body. The real trouble happens when someone violates the spec and sends unencoded text with characters outside the ASCII repertoire - then you have to use heuristics (or ISO2022 encoding if you're lucky) to guess which charset it is. Again, this isn't a problem with SMTP - the same problem would exist for any mail transmission protocol carrying MIME messages. If you went to a new mail format and forced everyone to use UTF-8, you could dispense with that problem (at a huge cost). Last I knew there were still large groups who were not happy with the ISO 10646/Unicode repertoire.
Yes, you can and should have the ability to trust multiple CAs, and in fact I was assuming that this would be the case. My point was that it is extremely difficult to deploy this on a sufficiently wide scale that any legitimate party can send mail to an arbitrary recipient.
I disagree with you about SMTP, first the authentication sucks, secondly the need to encode binary data is a major shortcoming.
SMTP authentication uses SASL so it's very extensible. It can support public key authentication via either GSSAPI or TLS client certificates (using AUTH EXTERNAL). As for transmission of binary data, that's been standardized for several years; see RFC 3030.
SMTP already has authentication, and anyone who operates an SMTP server is free to accept or not accept mail from whomever he wants. You don't need a new protocol to require mail to be authenticated. If you can solve the trust problem, you can implement a trusted mail solution more quickly and easily with SMTP than by requiring deployment of an entirely new protocol.
NAT breaks nothing except applications stupid enough to put their local IP inside the data they send.
As it turns out, there are good reasons to do precisely that in distributed applications. DNS is neither fast nor reliable enough to serve as a substitute for IP addresses in all situations. Furthermore the Internet was designed to have a global address space, in fact the Internet Protocol depends on this working because IP routers make routing decisions independently. Networks using private address space cannot exchange routing information with the Internet or with other networks, they have to NAT everything at their borders.
What you are calling IP Masquerading is generally called NAPT - Network Address and Port Translation - in the RFCs. NAPT generally implies that the network is not able to accept unsolicited traffic to arbitrary hosts (because there's no way for the NAPT to know where the traffic goes) but in practice this limitation applies to most NATs even if they are not configured to do NAPT.
I'm amused that you think my complaints are invalid when they are breaking fundamental design features of the Internet Protocol and they are preventing the ability of many useful applications to work. Oh well, these days vendors can get away with breaking whatever they want, and not suffer any pain from doing so.
I don't think that's a valid assumption. But it's probably more accurate to say that NAT users don't realize that the fact that they have NATs installed means that some useful applications are not available to them - like standards-based Internet telephony (just to name one example). NATs are so widely deployed that they've killed the potential market for some very useful apps that happen to need the ability to send unsolicited traffic to hosts. If you had a plain firewall you could selectively enable that particular app; but with a NAT (at least, a NAT that multiplexes several internal addresses onto one external one) you can't do that - the NAT actually has to have code that knows about your app protocol in order to make this work, and sometimes that's simply not feasible.
As for the shortage of IPv4 address space, it's real. It's just that the shortage you are seeing is caused by the real shortage. If the restrictions on address allocation were not in place, China alone would consume the remaining addresses tomorrow.
that's because you haven't tried to write distributed apps that work across NATs...
here is a list of NAT problems that I cons'ed up because I got tired of trying to explain this over and over.
there's no way to fix NAT without having a global address space, and that's precisely what NAT takes away. various groups have tried in vain to fix NAT (RSIP, MIDCOM, HIP) and all of the solutions are of limited applicability.
The real blame for IPv6, DNSSEC and IPSEC being nowhere is the IETF. And before ACs come back telling me that IPSEC is widely used for VPNs, yes I know, but a VPN is not what IPSEC is designed for. IPSEC was intended to be INTERNET security.
IPsec may have been intended for Internet security, but it suffers from several assumptions that were obsolete years ago - namely that hosts are meaningful as security principals, and IP addresses are good names for hosts. HIP goes a long way to alleviate some of those problems. The other thing that IPsec needs is a good API to make it accessible to applications, and in particular to allow applications to set their own authentication credentials and use their own security policies.
But I'd agree that IPsec hasn't turned out to be a boon for IPv6 - if anything it has delayed IPv6 deployment without adding useful functionality. Hindsight is perfect, of course.
As for your remarks about IETF, personally I don't find namedropping (either of those who are contributing to IETF or those who aren't) makes very useful criticism.
Of course, you are a nominal author of this RFC, Keith, so I suspect this is something you already knew. Right?
Frankly I'd forgotten that this was in 2804.
Keith
well, it won't be a standard - so if someone holds up such a document, they'll be lying. of course, lies aren't exactly a new invention.
IPv6 is irrelevant for this discussion. you don't necessarily have to upgrade your router to route IPv6 (especially if it supports MPLS). and if you do decide to upgrade to IPv6 it will be because of customer demand for it and/or the shortage of IPv4 addresses not because of some Cisco conspiracy.
for that matter if you install the hardware and software necessary to support LE surveillance then it won't be because Cisco forced you to do so but because the government forced you to do so. otherwise, you wouldn't spend the extra money.
yep, there's definitely something to be said for making people aware of how governments are spying on them. though not many people read RFCs.
it's just a draft by one guy. anybody can submit a draft. it doesn't mean anything in terms of IETF approval. however since it purports it might eventually get published as an Informational document (not a standard).
if you think this is a transparent attempt to get IETF to appear to endorse a heinous activity (as I do) then you might want to write the IESG and/or the RFC Editor (as I intend to) and object to such publication. in order to avoid flooding their normal mailboxes, perhaps someone would like to set up a mailing list?
when governments think they have the right to kill thousands of people with scant justification, the last thing we need is to help them standardize on surveillance technologies.
Sadly, this summary is still pretty complete.
As other people have pointed out, this is not an IETF working group - it's an IRTF research group, and as such its purpose is to try to understand the problem and the solution space rather than to propose a concrete solution for standardization. Many of the folks in the group don't seem to have figured this out yet either. As a result there have been a number of naive proposals for how to solve the problem, along with a huge number of arguments of the form "your proposal is broken in X way".
But the group just got started a few days ago, and is only barely starting to move in any particular direction. Trying to make any predictions about the group's eventual output from what has been discussed so far is probably not a useful exercise.
I would say in the air you have an infinite number of possible paths, on ground you only have very expensive roads.
an infinite number of possible paths actually provides more opportunities for paths to cross. that and just because there are an infinite number of possible paths does not mean that everyone will choose a random path. most pilots with gps would prefer to fly a straight line between source and destination, which means that for popular source,destination pairs there are only a few paths. in some places, and at some times, paths are also constrained by weather and terrain.
I'm almost positive that a consumer vehicle in the range of $10k-$30k is capable of surviving a 10 story fall without any bodily harm, in fact the driver might be better off due to the delay before the "big crash".
making a vehicle that can survive the fall and still be light enough to fly cheaply is a serious engineering challenge. protecting the human body from such a fall is even harder. our skeletons are much better at dealing with horizontal impact than vertical impact. parachutes are probably the best bet, but they do add to the cost.
There already exist proximity avionics that will alert the pilots of two planes flying close or in an intercept course that they need to watch out for another aircraft.
indeed, though such devices are not cheap. perhaps economies of scale would drive the costs down, though the transponders and TCAS would also have to get a lot more sophisticated than they are now.
also note that being able to survive the occasional screwup by ATC, pilot deviating from a clearance, or failure of a pilot to see and avoid another aircraft in visual conditions - is not anything like the same thing as being able to avoid hundreds of thousands of aircraft piloted by fellow commuters - everyone trying to get home from work.
air traffic control is probably the biggest problem.
the ATC system is already overtaxed in busy areas and part of how they cope is by discouraging general aviation. it's certainly technically feasible for personal aircraft to be reliable, affordable, and about as easy to fly as it is to drive a car IF you can get enough people to use them. but if you get enough people to use them you have a traffic management problem far worse than anything we've ever seen on the ground.
face it, one reason we want to travel by air is to avoid traffic jams - but as soon as we put everyone in the air we need to find ways to keep everyone from hitting each other, and to do that we end up imposing the same kinds of constraints we have on the ground. at least on the ground we can often survive collisions between vehicles.
Keith
actually, numbers are great. they are terse, they work on any keyboard in the world (including telephone keyboards), and they are language-independent. and when you think about it, phone numbers really aren't much less mnemonic than the local-part of a typical big-ISP email address.
of course, nobody's suggesting that we use numbers instead of email addresses or URLs, but addresses that consist of nothing but digits are in fact quite useful.
and anyway, enum is only half of the picture - there's also a proposal for mapping URLs to other information from the rescap working group. The basic idea is that an identifier should not be inherently tied to one single kind of resource - given either a phone number or a URL (and the latter includes email addresses), you should be able to find out additional information about that resource if the owner of that number/URL wants to provide it. phone number to web page? easy.
email address to phone number? sure, if I want to provide it. or maybe you have my voice # and want to send me email. again, no problem.