RE: quietly....
And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. In IP, all hosts/nodes are peers. That you may wish that this were not the case and thereby impose completely arbitrary paper based controls does not in any way change the fact that IP is a peer to peer protocol and that all IP hosts/nodes are peers on the network. Your paper based controls are just as effective in turning an IP host/node into a non-peer host/node as is holding up a copy of a restraining order preventing Johhny X from hitting you in the face in front of Johhny's fist just before he breaks your nose. That you believe that your paper controls have any effect on reality is saddening. Just because someone writes a bit of paper saying that the moon is made of green cheese does not make it so. Writing on a bit of paper that IP is not a peer-peer protocol does not make it so. If your security is based on such wishful thinking and self-delusion, you really ought to invest in some technical controls that are reality-based and stop with the paper-compliance-tiger as it provides no useful benefit whatsoever. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org -Original Message- From: Matthew Huff [mailto:mh...@ox.com] Sent: Thursday, 03 February, 2011 16:41 To: Matthew Palmer; nanog@nanog.org Subject: RE: quietly SMTP is definitely not a p2p protocol in most corporate environments. In ours, all email (even ones that you would think should be host2host) go to a central smarthost that processes the mail, and archive it for compliance. All internal to external and external to internal email is tightly controlled and only goes through a very specific route. Again, big difference between a univerisity or ISP environment and a corporate one. -Original Message- From: Matthew Palmer [mailto:mpal...@hezmatt.org] Sent: Thursday, February 03, 2011 4:00 PM To: nanog@nanog.org Subject: Re: quietly On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote: On Thursday, February 03, 2011 02:28:32 pm valdis.kletni...@vt.edu wrote: The only reason FTP works through a NAT is because the NAT has already been hacked up to further mangle the data stream to make up for the mangling it does. FTP is a in essence a peer-to-peer protocol, as both ends initiate TCP streams. I know that's nitpicking, but it is true. So is SMTP, by the same token. Aptly demonstrating why the term P2P is so mind-alteringly stupid. - Matt
Re: quietly....
On 2/19/2011 10:11 AM, kmedc...@dessus.com wrote: And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. SMTP as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: quietly....
My understanding of peer-to-peer was that it indicated that all hosts had equal ability to originate or terminate (as in accept, not as in end) sessions. That is, the role of client or server is defined by the choice of the application and/or software on the host and not by the network. IP is a peer to peer network because all nodes are equal at the protocol level. IP does not make a protocol-level distinction between clients or servers. See: http://en.wikipedia.org/wiki/Peer-to-peer Noting specifically from http://en.wikipedia.org/wiki/Client-server#Comparison_to_peer-to-peer_architecture It would appear to me that IP is, by definition peer to peer while TCP seems inherently client-server in most implementations and UDP is ambiguous and can be used in either mode, as in DNS where a recursive resolver operates simultaneously as both a server and a client or peer and an authoritative server with secondaries also operates simultaneously as a server and as a peer. You are correct about the peer to peer or not nature of an architecture being possibly different at different layers, but, I don't think you are right in saying that having routers in between makes two IP nodes not peers. Owen On Feb 19, 2011, at 11:42 AM, Dave CROCKER wrote: On 2/19/2011 10:11 AM, kmedc...@dessus.com wrote: And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. SMTP as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: quietly....
On 2/19/2011 10:11 AM, kmedc...@dessus.com wrote: And that has nothing to do with whether a protocol is a peer protocol or not. IP is a peer-to-peer protocol. As SMTP is implemented over IP, it is also a peer-to-peer protocol. At each layer of an architecture, the question of whether a mechanism is peer to peer can be newly defined. Even within a layer it can be, depending upon configuration choices. IP is typically /not/ peer to peer, since getting from the originating host to the target host is typically mediated by many routers. That is the essence of /not/ being peer to peer. One layer up, we find that TCP typically /is/ peer-to-peer. SMTP as a one-hop email transmission protocol is peer-to-peer from the SMTP client to the corresponding SMTP server. However email exchange from an author's MUA to a recipient's MUA is, again, the essence of /not/ being peer to peer. It is typically massively mediated by lots of different email servers. One could configure two MUAs to talk with each other 'directly' using SMTP, but that's never done. Instant message services similarly are not peer-to-peer technical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: quietly....
On Tuesday, February 15, 2011 11:57:46 pm Jay Ashworth wrote: From: Michael Dillon wavetos...@googlemail.com This sounds a lot like bellhead speak. As a long time fan of David Isen, I almost fell off my chair laughing at that, Michael: Bell *wanted* things -- specifically the network -- smart and complicated; Isen's POV, which got him... well, I don't know if laughed out of ATT is the right way to phrase it, but it's close enough, was: Stupid network; smart endpoints. The bellhead PoV isn't wrong; it's just different. Stupid endpoints tend to be more usable when such usage matters, such as emergencies (power outages, need to call 911, etc). The problem is we're in neither of the two worlds at the moment; we're in between, with complex/smart networks (QoS, etc) and smart/complex endpoints. Which, IMO, is the worst of both worlds. Stupid network and smart endpoint: a smart endpoint user or said user's tech person has a chance to fully troubleshoot and correct issues; Smart network and stupid endpoint: net op tech has a chance to fully troubleshoot and correct issues; Smart network and smart endpoint: nobody can fully troubleshoot anything, and much fingerpointing and hilarity ensues
Re: quietly....
On 14 feb 2011, at 6:46, Frank Bulk wrote: Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. I don't get this. Why spend cycles discovering a value that doesn't need to change? But I lost this argument in the IETF years ago, so I guess I'm relatively alone here.
Re: quietly....
On 2/15/2011 5:08 AM, Iljitsch van Beijnum wrote: On 14 feb 2011, at 6:46, Frank Bulk wrote: Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. I don't get this. Why spend cycles discovering a value that doesn't need to change? Because it will change. At some point, this paradigm will shift. The service hierarchy will change, the protocol methodology will change, the network topology will change... *something* will happen that will make a well-known address, hard-coded in a million places, change from a boon to a massive headache. One of the biggest problem v6 seems to have had is that its designers seemed to think the problem with v4 was that it didn't have enough features. They then took features from protocols that ipv4 had killed over the years, and added them to v6, and said, Look, I made your new IP better. And then, when the operators groaned and complained and shook their heads, the ipv6 folks called them backward and stuck in ipv4-think. But the fact of the matter is, operators want a protocol to be as simple, efficient, flexible, and stupid as possible. They don't want the protocol tied to how things work today; it needs to be open to innovation and variety. And part of that is that an address needs to be just an address, with no other significance other than being unique and routable. The moment an address has any significance beyond the network layer, it's a liability waiting to happen.
Re: quietly....
On 2/15/2011 11:28 AM, David Israel wrote: They don't want the protocol tied to how things work today; it needs to be open to innovation and variety. And part of that is that an address needs to be just an address, with no other significance other than being unique and routable. The moment an address has any significance beyond the network layer, it's a liability waiting to happen. +1 The rare exception being multicast. :) Jack
Re: quietly....
On Tue, 15 Feb 2011 11:08:01 +0100, Iljitsch van Beijnum said: On 14 feb 2011, at 6:46, Frank Bulk wrote: Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. I don't get this. Why spend cycles discovering a value that doesn't need to change? You've obviously never had to change a number in a /etc/resolv.conf because the number you've listed has gone bat-guano insane. If the root DNS address becomes a magic IP address (presumably some variety of anycast), it becomes a lot harder to change to another address if the closest anycast address goes insane. If root nameserver F (or merely the anycast instance I can see) goes bonkers(*), I can say screw this, ask G and K instead. You can't do that if G and K are the same magic address as F. (*) bonkers for whatever operational definition you want - wedged hardware, corrupted database, coercion by men with legal documents and firearms, whatever. pgp2qaoKrekTz.pgp Description: PGP signature
Re: quietly....
On 2/15/2011 11:41 AM, valdis.kletni...@vt.edu wrote: (*) bonkers for whatever operational definition you want - wedged hardware, corrupted database, coercion by men with legal documents and firearms, whatever. Route injected by foreign parties into BGP. Also a reason not to have them even close together. Jack
Re: quietly....
One of the biggest problem v6 seems to have had is that its designers seemed to think the problem with v4 was that it didn't have enough features. They then took features from protocols that ipv4 had killed over the years, and added them to v6, and said, Look, I made your new IP better. And then, when the operators groaned and complained and shook their heads, the ipv6 folks called them backward and stuck in ipv4-think. But the fact of the matter is, operators want a protocol to be as simple, efficient, flexible, and stupid as possible. They don't want the protocol tied to how things work today; it needs to be open to innovation and variety. This sounds a lot like bellhead speak. The fact is that IP of any version was made for the users of network, not just for the privileged few who operate them. Compromises had to be made so, in the end, IPv6 is not perfect. But why should it be? There is a process for changing and updating IPv6. Use it! But implement what we have now as best you can.
Re: quietly....
- Original Message - From: Michael Dillon wavetos...@googlemail.com folks called them backward and stuck in ipv4-think. But the fact of the matter is, operators want a protocol to be as simple, efficient, flexible, and stupid as possible. They don't want the protocol tied to how things work today; it needs to be open to innovation and variety. This sounds a lot like bellhead speak. As a long time fan of David Isen, I almost fell off my chair laughing at that, Michael: Bell *wanted* things -- specifically the network -- smart and complicated; Isen's POV, which got him... well, I don't know if laughed out of ATT is the right way to phrase it, but it's close enough, was: Stupid network; smart endpoints. That seems entirely compatible with the proposed preference for IPv6 which you dismiss above as Bellhead. Cheers, -- jra
Re: quietly....
On 2/3/11 12:59 PM, David Conrad wrote: On Feb 3, 2011, at 5:35 AM, Jack Bates wrote: You missed my pointed. Root servers are hard coded, but they aren't using a well known anycast address. Actually, most of the IP addresses used for root servers are anycast addresses and given they're in every resolver on the Internet, they're pretty well known... Of course, one might ask why those well known anycast addresses are owned by 12 different organizations instead of being golden addresses specified in an RFC or somesuch, but that gets into root server operator politics... there are perfectly valid reasons why you might want to renumber one, the current institutional heterogeneity has pretty good prospects for survivability. Regards, -drc
Re: quietly....
On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: Of course, one might ask why those well known anycast addresses are owned by 12 different organizations instead of being golden addresses specified in an RFC or somesuch, but that gets into root server operator politics... there are perfectly valid reasons why you might want to renumber one, Ignoring historical mistakes, what would they be? the current institutional heterogeneity has pretty good prospects for survivability. Golden addresses dedicated to root service (as opposed to 'owned' by the root serving organization) means nothing regarding who is operating servers behind those addresses. It does make it easier to change who performs root service operation (hence the politics). Regards, -drc
Re: quietly....
- Original Message - From: David Conrad d...@virtualized.org On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: Of course, one might ask why those well known anycast addresses are owned by 12 different organizations instead of being golden addresses specified in an RFC or somesuch, but that gets into root server operator politics... there are perfectly valid reasons why you might want to renumber one, Ignoring historical mistakes, what would they be? the current institutional heterogeneity has pretty good prospects for survivability. Golden addresses dedicated to root service (as opposed to 'owned' by the root serving organization) means nothing regarding who is operating servers behind those addresses. It does make it easier to change who performs root service operation (hence the politics). Exactly: it *centralizes control* over what the roots are. The second- and third-order resultants of that observation will be left as an exercise for the student; politics are off-topic for NANOG :-) Cheers, -- jra
Re: quietly....
On 2/13/11 10:31 AM, David Conrad wrote: On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: Of course, one might ask why those well known anycast addresses are owned by 12 different organizations instead of being golden addresses specified in an RFC or somesuch, but that gets into root server operator politics... there are perfectly valid reasons why you might want to renumber one, Ignoring historical mistakes, what would they be? gosh, I can't imagine why anyone would want to renumber of out 198.32.64.0/24... making them immutable pretty much insures that you'll then find a reason to do so. the current institutional heterogeneity has pretty good prospects for survivability. Golden addresses dedicated to root service (as opposed to 'owned' by the root serving organization) means nothing regarding who is operating servers behind those addresses. It does make it easier to change who performs root service operation (hence the politics). There are plenty of cautionary tales to be told about well-known addresses. assuming that for the sake of the present that we forsake future flexibility then sure golden addresses are great. Regards, -drc
Re: quietly....
On Sun, Feb 13, 2011 at 04:49:57PM -0800, Joel Jaeggli wrote: On 2/13/11 10:31 AM, David Conrad wrote: On Feb 13, 2011, at 7:56 AM, Joel Jaeggli wrote: Of course, one might ask why those well known anycast addresses are owned by 12 different organizations instead of being golden addresses specified in an RFC or somesuch, but that gets into root server operator politics... there are perfectly valid reasons why you might want to renumber one, Ignoring historical mistakes, what would they be? gosh, I can't imagine why anyone would want to renumber of out 198.32.64.0/24... or 198.32.65.0/24 or 10.0.0.0/8 or 128.0.0.0/16 (speaking of the other blocks I've had the fortune to have to renumber out of) making them immutable pretty much insures that you'll then find a reason to do so. the current institutional heterogeneity has pretty good prospects for survivability. Golden addresses dedicated to root service (as opposed to 'owned' by the root serving organization) means nothing regarding who is operating servers behind those addresses. It does make it easier to change who performs root service operation (hence the politics). There are plenty of cautionary tales to be told about well-known addresses. assuming that for the sake of the present that we forsake future flexibility then sure golden addresses are great. Regards, -drc well - there is an interesting take on hosting root name service on 127.0.0.1 and ::1 then you have to do other tricks, like multicast and new op-codes and rip out the link-local restrictions that Apple's multicastDNS or the ilnp proposals do... end of the day, you end up with a -much- more robust DNS w/o the whole P2P/DNS (chord) like framework. but ... this thread has migrated far from its origins... and the mutations are less than operational. YMMV of course. --bill
Re: quietly....
On Feb 13, 2011, at 2:49 PM, Joel Jaeggli wrote: Ignoring historical mistakes, what would they be? gosh, I can't imagine why anyone would want to renumber of out 198.32.64.0/24... I guess you missed the part where I said Ignoring historical mistakes. making them immutable pretty much insures that you'll then find a reason to do so. The fact that ICANN felt it necessary to renumber into a new prefix is a perfect example of why having golden addresses for the DNS makes sense. If the root server addresses had been specified in an RFC or somesuch, there would be no question about address ownership. There are plenty of cautionary tales to be told about well-known addresses. As I'm sure you're aware, the DNS is a bit unique in that can't use the DNS to bootstrap. It requires a set of pre-configured addresses to function. Changing one of those pre-configured addresses requires changing the hints file in every resolver on the Internet which takes a very long time (I'm told that a root server address changed over a decade ago still receives more than 10 priming queries per second). It also means the former root server address is forever poisoned -- you don't want to give that address to someone who might use it to set up a bogus root server. It was hard enough when there were just a couple of DNS resolver vendors, now there are more than a few. assuming that for the sake of the present that we forsake future flexibility then sure golden addresses are great. It isn't clear to me what flexibility would be sacrificed, but it is academic. Unfortunately, it'll likely take some traumatic event for the status quo to change. Regards, -drc
RE: quietly....
Ditto. -Original Message- From: Jack Bates [mailto:jba...@brightok.net] Sent: Tuesday, February 01, 2011 11:02 PM To: NANOG list Subject: Re: quietly snip I have also now seen 2 different vendor DSL modems which when not using PPPoE require a manually entered default router (ie, no RA support). Jack
RE: quietly....
Sounds like PI space is a solution for those 5000 desktops. Frank -Original Message- From: david raistrick [mailto:dr...@icantclick.org] Sent: Wednesday, February 02, 2011 11:05 AM To: Cameron Byrne; Owen DeLong Cc: nanog@nanog.org Subject: Re: quietly On Tue, 1 Feb 2011, Cameron Byrne wrote: Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. +1 Somebody should probably get a blog instead of sending, *39 and counting*, emails to this list in one day. It's a discussion list. We're having a discussion. Admittedly, Owen hasn't presented any solutions to my actual problems, but.. ;) Owen said: The solution to number 2 depends again on the circumstance. IPv6 offers a variety of tools for this problem, but, I have yet to see an environment where the other tools can't offer a better solution than NAT. Which is a complete non-answer. NAT provides a nice solution - even with it's problems - for small consumers and large enterprises, who have much higher percentages of devices that need (or even -require-) no inbound connectivity. Why should I (or my IT department) have to renumber the 5,000 desktop PCs in this office (a large percentage of which have static IP addresses due to the failings of dynamic DNS and software that won't support DNS (I'm looking at you, Unity.) just because we've changed providers? Why should we have to renumber devices at my mom's house just because she switched from cable to dsl? -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
RE: quietly....
Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. Frank -Original Message- From: Iljitsch van Beijnum [mailto:iljit...@muada.com] Sent: Wednesday, February 02, 2011 9:23 AM To: Owen DeLong Cc: NANOG list Subject: Re: quietly On 2 feb 2011, at 16:00, Owen DeLong wrote: SLAAC fails because you can't get information about DNS, NTP, or anything other than a list of prefixes and a router that MIGHT actually be able to default-route your packets. Who ever puts NTP addresses in DHCP? That doesn't make any sense. I'd rather use a known NTP server that keeps correct time. For DNS in RA, see RFC 6106. But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. DHCP fails because you can't get a default router out of it. If you consider that wrong, I don't want to be right.
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On Sat, Feb 5, 2011 at 5:34 PM, Derek J. Balling dr...@megacity.org wrote: On Feb 5, 2011, at 8:14 PM, Mark Andrews wrote: I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Wow... Could that be any more of a waste of yours and their time? This is like telling the cashier at the hospital when you're being discharged, y'know, I'm not sure that they're using the proper stitch-knot in the ER. You should have someone look at that. Do you honestly think that feedback is even *understood*, let alone passed on to anyone even close to the problem? Well, around here the front desk would pass it along and it would reach me; more so if they don't understand it. Though if it wasn't in writing, it would probably become unintelligible. Am I in a position to do something about it? Probably not.
RE: quietly....
The end-to-end model is about If my packet is permitted by policy and delivered to the remote host, I expect it to arrive as sent, without unexpected modifications. Well, it's about communications integrity being the responsibility of the endpoint. It is therefore expected that the network not mess with the communication. See http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Nobody wants to get rid of firewalls. Several people want to get rid of firewalls. Consistent with the end-to-end principle, hosts should provide their own policy enforcement. See expired draft-vyncke-advanced-ipv6-security-01 Unfortunately, the approach described doesn't work in state-of-the-art residential CPE, and relies heavily on endpoint security protection, which is weak in most Internet hosts. We want to get rid of NAT. Firewalls work great without NAT and by having firewalls without NAT, we gain back the end-to-end model while preserving the ability to enforce policy on end-to-end connectivity. I would rather see hosts protect themselves from badness, and network security appliances be limited to protecting against network threats (a DDOS is a network threat; a service DOS is an application threat). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. Service discovery is an Internet weakness. NAT does destroy end-to-end. Firewalls do not. Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee
Re: quietly....
sure From: Lee Howard l...@asgard.org To: Owen DeLong o...@delong.com; david raistrick dr...@icantclick.org Cc: nanog@nanog.org Sent: Sun, February 6, 2011 2:16:35 PM Subject: RE: quietly The end-to-end model is about If my packet is permitted by policy and delivered to the remote host, I expect it to arrive as sent, without unexpected modifications. Well, it's about communications integrity being the responsibility of the endpoint. It is therefore expected that the network not mess with the communication. See http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Nobody wants to get rid of firewalls. Several people want to get rid of firewalls. Consistent with the end-to-end principle, hosts should provide their own policy enforcement. See expired draft-vyncke-advanced-ipv6-security-01 Unfortunately, the approach described doesn't work in state-of-the-art residential CPE, and relies heavily on endpoint security protection, which is weak in most Internet hosts. We want to get rid of NAT. Firewalls work great without NAT and by having firewalls without NAT, we gain back the end-to-end model while preserving the ability to enforce policy on end-to-end connectivity. I would rather see hosts protect themselves from badness, and network security appliances be limited to protecting against network threats (a DDOS is a network threat; a service DOS is an application threat). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. Service discovery is an Internet weakness. NAT does destroy end-to-end. Firewalls do not. Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee
Re: quietly....
Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee I would be fine with that. However, in terms of the art of the possible with the tools available today, IPv6 has no need of NAT, but, firewalls cannot yet be safely removed from the equation. Owen
Re: quietly....
In article 85d304ba-6c4e-4b86-9717-2adb542b8...@delong.com, Owen DeLong o...@delong.com writes Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? If they don't document partial internet access blockage in the contract and the contract says they are providing internet access, then, they are in breach and you are free to depart without a termination fee and in most cases, demand a refund for service to date. You may be right about enforcing that in the USA (is it an FCC thing?), but it won't fly in most other places. Admittedly, I'm not over-fussed about email on my phone and I don't use a tether device at this point. The 3G I'm discussing is a dongle intended for general access. I mostly expect 3G and 4G networks to be broken internet anyway. I was more speaking in terms of land-line providers. Apparently there are something like three times as many people with mobile phones in the world, as with Internet access. And a lot of network expansion is expected to be based on mobile connectivity as a result. -- Roland Perry
Re: quietly....
In article 20110205131510.be13e9b5...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? You return the equipment as not suitable for the advertised purpose and demand your money back. Renumbering is expected to occur with IPv6, part of renumbering is getting the name to address mappings right. With DHCP the DHCP server normally does it. With SLAAC the host has to do it as there is no other choice. Here in Australia it is Repair/Replace/Refund if the product purchased is faulty. That applies to all products. If the milk is off when we get home we go back and get it replaced and if the store is out of stock we get a refund. I've returned and had replaced plenty of stuff over the years. I think you are just confirming my view that moving from IPv4 to IPv6 will involve more than the ISP doing some magic that's transparent to the majority of users. And good luck returning a 3 year old PS/3 for a refund on the basis it doesn't support IPv6. -- Roland Perry
Re: quietly....
On Feb 6, 2011, at 9:49 AM, Roland Perry wrote: In article 20110205131510.be13e9b5...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? You return the equipment as not suitable for the advertised purpose and demand your money back. Renumbering is expected to occur with IPv6, part of renumbering is getting the name to address mappings right. With DHCP the DHCP server normally does it. With SLAAC the host has to do it as there is no other choice. Here in Australia it is Repair/Replace/Refund if the product purchased is faulty. That applies to all products. If the milk is off when we get home we go back and get it replaced and if the store is out of stock we get a refund. I've returned and had replaced plenty of stuff over the years. I think you are just confirming my view that moving from IPv4 to IPv6 will involve more than the ISP doing some magic that's transparent to the majority of users. And good luck returning a 3 year old PS/3 for a refund on the basis it doesn't support IPv6. -- Roland Perry I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. Owen
Re: quietly....
- Original Message - From: Owen DeLong o...@delong.com I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from optimistic to nutsabago. :-) From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. Cheers, -- jra
Re: quietly....
On Feb 6, 2011, at 1:15 PM, Owen DeLong wrote: If you advertise a product as internet access, then, providing limited or partial access to the internet does not fulfill the terms of the contract unless you have the appropriate disclaimers. And in nearly every ISP's terms-of-service, which you agree to the terms and conditions of by becoming a customer, there's invariably clauses in there that give them all sorts of rights to filter traffic at their discretion, etc., etc. D
Re: quietly....
On Feb 6, 2011, at 10:34 AM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from optimistic to nutsabago. :-) No. I believe I can force through legal choices hotel providers to refund my internet access charges if they block certain ports. I've done so. I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. An interesting perspective. The problem with that theory is that nobody actually manages the internet. It is a collection of independently managed networks that happen to coordinate, cooperate, and collaborate on a limited basis to make certain things work. I agree with you that many organizations and individuals could have acted differently to achieve a more optimal transition. However, they didn't and we are where we are. As a result, I think it is far more productive to move forward and make the transition as quickly and effectively as possible than to dwell on claims of mismanagement which lack both a meaningful target and any form of useful resolution. Owen
Re: quietly....
On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. Sony appears quite willing to file eye-openingly broad discovery requests in its OtherOS/geohotz lawsuit(s). Related, but separate, Sony appears to be unconcerned with the removal of OtherOS in the first place, a documented feature and selling point that's made some people unhappy (e.g. USAF). And Sony appears completely unconcerned about the Sony RootKit fiasco (Most people, I think, don't even know what a Rootkit is, so why should they care about it?). Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York he...@aegis00.com (800) 234-4700
Re: quietly....
On Feb 6, 2011, at 11:11 AM, Henry Yen wrote: On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. Sony appears quite willing to file eye-openingly broad discovery requests in its OtherOS/geohotz lawsuit(s). Related, but separate, Sony appears to be unconcerned with the removal of OtherOS in the first place, a documented feature and selling point that's made some people unhappy (e.g. USAF). And Sony appears completely unconcerned about the Sony RootKit fiasco (Most people, I think, don't even know what a Rootkit is, so why should they care about it?). Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. While Sony is, indeed, showing surprising market ignorance and bad judgment at the moment, I think that the market will eventually teach them a lesson in these regards. Time will tell. Owen
Re: quietly....
Once upon a time, Henry Yen he...@aegisinfosys.com said: On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. Also, lack of functionality in the current generation can be seen by management as _good_ for future sales (of the PS4, the Xbox 720, WiiToo, etc.). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: quietly....
On Feb 6, 2011, at 2:28 PM, Owen DeLong wrote: While Sony is, indeed, showing surprising market ignorance and bad judgment at the moment, I think that the market will eventually teach them a lesson in these regards. Time will tell. It is worth correlating that there seems to be some agreement to surprising market ignorance in the feature set and implementation of IPv6 as it pertains to the demands of its myriad actual consumers, and that the market will eventually teach the designers of IPv6 a lesson in that regard. That sword has edges on both sides, my friend. :-) cheers, D
Re: quietly....
On 2/6/2011 2:53 PM, Derek J. Balling wrote: It is worth correlating that there seems to be some agreement to surprising market ignorance in the feature set and implementation of IPv6 as it pertains to the demands of its myriad actual consumers, and that the market will eventually teach the designers of IPv6 a lesson in that regard. I don't think it's a concern or issue. Everyone will just have to buy an xbox. M$ can't claim ignorance. :) Jack
Re: quietly....
In message 23119638.5335.1297017284299.javamail.r...@benjamin.baylink.com, Ja y Ashworth writes: - Original Message - From: Owen DeLong o...@delong.com I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from optimistic to nutsabago. :-) From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. Cheers, -- jra PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On 2/6/2011 4:44 PM, Mark Andrews wrote: PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. I could be wrong, but I believe the PS3, like many game systems, has trouble with double NAT and supports end node game hosting, which will break with double NAT on both ends; we'll see double NAT commonly on both end points as we move forward if IPv4 is bothered to be supported for long, especially if ds-lite doesn't become more prevalent in CPEs. Jack
Re: quietly....
In message 4d4f27e4.6080...@brightok.net, Jack Bates writes: On 2/6/2011 4:44 PM, Mark Andrews wrote: PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. I could be wrong, but I believe the PS3, like many game systems, has trouble with double NAT and supports end node game hosting, which will break with double NAT on both ends; we'll see double NAT commonly on both end points as we move forward if IPv4 is bothered to be supported for long, especially if ds-lite doesn't become more prevalent in CPEs. Note the CPE doesn't have to be the box they is offering the IPv4 connectivity to the net. Any dual stack box on the net could do the job provided it supports the B4 component. Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On 2011-02-03, at 18:37, Paul Graydon wrote: On 02/02/2011 06:31 PM, Jay Ashworth wrote: I, personally, have been waiting to hear what happens when network techs discover that they can't carry IP addresses around in their heads anymore. That sounds trivial, perhaps, but I don't think it will be. Absolutely, it's certainly one thing I'm dreading. I'm not sure this is the nightmare people think it will be. In my (admittedly fairly small-scale) experience with operating v6 on real networks, being able to figure out a prefix from a schema such as ARIN:ARIN:SITE:VLAN::/64 makes things a lot easier. Having to remember ...::1, or ...::2, or ...:3 for the statically-numbered routers on the VLAN doesn't exactly make things much harder. Mix in some special cases (e.g. VLAN=0 for loopbacks) and you have a recipe that's pretty trivial to remember. [This is how Stephen Stuart and Paul Vixie set things up within 2001:4f8::/32 back when I was chasing packets at ISC, and I've followed the model ever since.] It's easier to figure out 2607:f2c0:1::1 in these terms than it is to remember 206.248.155.244. For me, at least :-) I appreciate the full mess of EUI-64 for devices using autoconf requires cut and paste, but that's why you hard-wire the host bits for things you refer to frequently. Joe
Re: quietly....
On 2/6/2011 6:13 PM, Joe Abley wrote: I'm not sure this is the nightmare people think it will be. In my (admittedly fairly small-scale) experience with operating v6 on real networks, being able to figure out a prefix from a schema such as ARIN:ARIN:SITE:VLAN::/64 makes things a lot easier. Having to remember ...::1, or ...::2, or ...:3 for the statically-numbered routers on the VLAN doesn't exactly make things much harder. Mix in some special cases (e.g. VLAN=0 for loopbacks) and you have a recipe that's pretty trivial to remember. As an ISP, we reserved the first /48 of several of our /32's for specific purposes, which makes it even easier. Our helpdesk will be running ping by number tests (for detecting IPv6 connectivity but DNS being broken) using: ARIN:ARIN::/64 Which makes it as easy as IPv4. This was made easier by the fact that our allocation has no letters. Jack
Re: quietly....
On 2/5/2011 1:37 AM, Owen DeLong wrote: Not sure how I feel about a more adaptive version. Sounds like it would be better than the current state, but, I vastly prefer I pay, you route. If I want filtration, I'll tell you. I generally agree with you. However, I also believe that every network has a responsibility to assist in the overall well being of the Internet as well as provide the best service they can to their customers. In general, this means maintaining network stability and stopping abuse when detected. The slowest and last resort of abuse handling is done by an abuse and/or security department responsible for handling complaints. Stopping things prior to a complaint (which sometimes don't come at all and sometimes is a screaming roar) is even better. http://www.merit.edu/mail.archives/nanog/2003-01/msg00579.html http://www.merit.edu/mail.archives/nanog/2003-08/msg00284.html Eh, you know all of them anyways, and it's taking forever to troll the archives. :) Filtering is an age old argument, though. I wish I could live without it, personally. Jack
Re: quietly....
In article alpine.bsf.2.00.1102041723070.54...@murf.icantclick.org, david raistrick dr...@icantclick.org writes But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once But (what I keep being told) you should never have to renumber! Get PI space and insert magic here! Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? [My current 3G supplier blocks port 25 sometimes, I've yet to work out the algorithm used, it flips every day or two]. So will the likes of Vodafone and t-mobile support the PI model described above? -- Roland Perry
Re: quietly....
In article 20110204225150.6fac49b2...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once every five years like I just did with my ADSL, or once every time the new ADSL hiccups[1] now that I have a CPE with 3G failover. [1] Seems to be about weekly, so far. And that can be pretty much automated these days. Windows boxes if you let them will just register their new addresses in the DNS. MacOS also has the ability to do this as well. You should be asking the other vendors for similar support. And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? [1] Quite by accident I have three net-connected items of theirs, a PS/3, a TV and a mobile phone. -- Roland Perry
Re: quietly....
In article f432e474-9725-4159-870a-d5432fe6e...@delong.com, Owen DeLong o...@delong.com writes What is important with IPv6 is to teach the generation of hammer-wielding mechanics who have grown up rarely seeing a screw and never knowing that there were wrenches that there are new tools available in IPv6. That screws or nuts and bolts can usually be superior to nails. That screws, nuts, and bolts work better if you install them with a screw driver or a wrench. That small brads lack structural integrity and that lag screws or bolts provide a superior structural hold when installed properly. That attempting to hammer every screw into a NAT-hole will destroy both the screw and the NAT-hole in most cases. This is all very true, but doesn't qualify (for my small-enterprise target audience) as not noticing the difference when the upstream network swaps from IPv4 to IPv6. I wonder what's the best way to get them up the necessary learning curve? [Maybe I should write a book about it] -- Roland Perry
Re: quietly....
On Feb 5, 2011, at 1:54 AM, Roland Perry wrote: In article alpine.bsf.2.00.1102041723070.54...@murf.icantclick.org, david raistrick dr...@icantclick.org writes But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once But (what I keep being told) you should never have to renumber! Get PI space and insert magic here! Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? If they don't document partial internet access blockage in the contract and the contract says they are providing internet access, then, they are in breach and you are free to depart without a termination fee and in most cases, demand a refund for service to date. (Yes, I have successfully argued this on multiple occasions). In fact, I get free internet in most of the more expensive hotel environments as a result. [My current 3G supplier blocks port 25 sometimes, I've yet to work out the algorithm used, it flips every day or two]. So will the likes of Vodafone and t-mobile support the PI model described above? I use SPRINT. They used to. They've stopped. Admittedly, I'm not over-fussed about email on my phone and I don't use a tether device at this point. I mostly expect 3G and 4G networks to be broken internet anyway. I was more speaking in terms of land-line providers. Owen (Who only depends on his current residential ISPs for L2 transport and doesn't know what they block at L3 and up as long as they don't break GRE)
Re: quietly....
In message xq1vy4e3bstnf...@perry.co.uk, Roland Perry writes: In article 20110204225150.6fac49b2...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once every five years like I just did with my ADSL, or once every time the new ADSL hiccups[1] now that I have a CPE with 3G failover. [1] Seems to be about weekly, so far. And that can be pretty much automated these days. Windows boxes if you let them will just register their new addresses in the DNS. MacOS also has the ability to do this as well. You should be asking the other vendors for similar support. And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? You return the equipment as not suitable for the advertised purpose and demand your money back. Renumbering is expected to occur with IPv6, part of renumbering is getting the name to address mappings right. With DHCP the DHCP server normally does it. With SLAAC the host has to do it as there is no other choice. Here in Australia it is Repair/Replace/Refund if the product purchased is faulty. That applies to all products. If the milk is off when we get home we go back and get it replaced and if the store is out of stock we get a refund. I've returned and had replaced plenty of stuff over the years. [1] Quite by accident I have three net-connected items of theirs, a PS/3, a TV and a mobile phone. -- Roland Perry -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
In message eqde49gvpstnf...@perry.co.uk, Roland Perry writes: In article f432e474-9725-4159-870a-d5432fe6e...@delong.com, Owen DeLong o...@delong.com writes What is important with IPv6 is to teach the generation of hammer-wielding mechanics who have grown up rarely seeing a screw and never knowing that there were wrenches that there are new tools available in IPv6. That screws or nuts and bolts can usually be superior to nails. That screws, nuts, and bolts work better if you install them with a screw driver or a wre nch. That small brads lack structural integrity and that lag screws or bolts prov ide a superior structural hold when installed properly. That attempting to hamme r every screw into a NAT-hole will destroy both the screw and the NAT-hole in most cases. This is all very true, but doesn't qualify (for my small-enterprise target audience) as not noticing the difference when the upstream network swaps from IPv4 to IPv6. It won't be a swap. Even when the local ISP can only deliver IPv6 they will still be able to get IPv4. There will be business which just deliver IPv4 to IPv6 only connected customers whether they need server support or client support or both. The software to do this is already written. I wonder what's the best way to get them up the necessary learning curve? Turn on IPv6 native or tunnel. Populate the IP6.ARPA space with individual PTR records for the machines. Add matching records. The outbound side should just work. Next you add records for all the services you offer after testing them. [Maybe I should write a book about it] -- Roland Perry -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Random Port Blocking at Hotels (was: Re: quietly....)
If they don't document partial internet access blockage in the contract and the contract says they are providing internet access, then, they are in breach and you are free to depart without a termination fee and in most cases, demand a refund for service to date. (Yes, I have successfully argued this on multiple occasions). In fact, I get free internet in most of the more expensive hotel environments as a result. It's more likely you get free internet service in expensive hotels because the guy/girl behind the front desk has been empowered to cancel out a ridiculously high charge for Internet when a guest starts jabbering at them about how the Internet didn't work for them for any reason, to keep the line moving and to make the guest happy, rather than any higher authority hunkering down with the CEO, legal staff, and CTO and saying by God, this Owen character is right, we're in breach of contract and his definition of the purity of Internet ports has so stunned us with its symmetry and loveliness that we shall bow down and sin no more! Thank you Mr. DeLong from making the blind see again! I mean, it's gratifying to think you've won the argument (hence: this is why they do it), but you could also have argued that they were giving out non-contiguous subnet masks or Class E addresses and it would have had the same effect. Try that next time and let us know how it works. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 j...@opus1.comhttp://www.opus1.com/jms
Re: Random Port Blocking at Hotels (was: Re: quietly....)
and saying by God, this Owen character is right, we're in breach of contract and his definition of the purity of Internet ports has so stunned us with its symmetry and loveliness that we shall bow down and sin no more! Thank you Mr. DeLong from making the blind see again! More likely uh, oh, we've got a loony one here. Maybe if I give him his ten bucks back, he'll go away. R's, John
Re: Random Port Blocking at Hotels (was: Re: quietly....)
In message 20110205150005.40621.qm...@joyce.lan, John Levine writes: and saying by God, this Owen character is right, we're in breach of contract and his definition of the purity of Internet ports has so stunned us with its symmetry and loveliness that we shall bow down and sin no more! Thank you Mr. DeLong from making the blind see again! More likely uh, oh, we've got a loony one here. Maybe if I give him his ten bucks back, he'll go away. R's, John I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Hotels ask for feedback on their services. If you see a fault report it in writing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On Feb 5, 2011, at 8:14 PM, Mark Andrews wrote: I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Wow... Could that be any more of a waste of yours and their time? This is like telling the cashier at the hospital when you're being discharged, y'know, I'm not sure that they're using the proper stitch-knot in the ER. You should have someone look at that. Do you honestly think that feedback is even *understood*, let alone passed on to anyone even close to the problem? D
Re: Random Port Blocking at Hotels (was: Re: quietly....)
I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Hotels ask for feedback on their services. If you see a fault report it in writing. Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
RE: Random Port Blocking at Hotels (was: Re: quietly....)
Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) John - I happen to know with absolute certainty that the above statement is false. But I'd be happy to take your money! :-) Nathan
Re: Random Port Blocking at Hotels (was: Re: quietly....)
In message alpine.bsf.2.00.1102052106001.53...@joyce.lan, John R. Levine wr ites: I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Hotels ask for feedback on their services. If you see a fault report it in writing. Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) The point I was trying to make is that hotel still needs to protect their customers from bad actions by other customers. Investing in RA guard gives their current customers a better experience *now* and is not a wasted expense as they will continue to need it when they get IPv6 connectivity. The alternative is to filter all IPv6 packets and remember to turn off the filter when they go to turn on IPv6. The RA guard can be configured to allow the hotels routers to work when IPv6 is finally enabled on them. Anyway it's all about educating people to be aware that they need to purchace stuff with IPv6 in mind even if they don't yet use IPv6. Anything bought now is likely to be used in a envionment with IPv6 enabled at some point. Mark Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies , Please consider the environment before reading this e-mail. http://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Random Port Blocking at Hotels (was: Re: quietly....)
In message bc81acea-8dea-4380-8a57-a4f570e3c...@megacity.org, Derek J. Balli ng writes: On Feb 5, 2011, at 8:14 PM, Mark Andrews wrote: I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Wow... Could that be any more of a waste of yours and their time? I put it writing so it could be sent to someone that could actually do something about it. I didn't expect the girl at the desk to do anything about it other than make sure the report got to the right department. I expressed in terms of this is a future problem and you need to be planning for it. Bitching about problems with hotels networks here doesn't get them fixed. Complaining, in writing, has a chance of getting the problem fixed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On 2/5/2011 8:06 PM, John R. Levine wrote: Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) http://twitter.com/unquietwiki/status/449593712050176 springs to mind -- it was even *last* year. I think you owe Mark $10. Jima
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On Feb 5, 2011, at 5:14 PM, Mark Andrews wrote: In message 20110205150005.40621.qm...@joyce.lan, John Levine writes: and saying by God, this Owen character is right, we're in breach of contract and his definition of the purity of Internet ports has so stunned us with its symmetry and loveliness that we shall bow down and sin no more! Thank you Mr. DeLong from making the blind see again! More likely uh, oh, we've got a loony one here. Maybe if I give him his ten bucks back, he'll go away. R's, John I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Hotels ask for feedback on their services. If you see a fault report it in writing. Rest assured, I do that as well. I also end up usually spending a fair amount of time on the phone with their contracted support desk which is usually staffed by people that can barely spell IP and get confused if you suffix it with v4 or v6. When I inquired about IPv4 and IPv6 support, I had one literally tell me We don't support either of those. Just ordinary Internet Protocol. Owen
Re: Random Port Blocking at Hotels (was: Re: quietly....)
John R. Levine wrote: I have told a hotel they need to install equipment that supports RA guard as I've checked out. This was a hotel that only offered IPv4. Hotels ask for feedback on their services. If you see a fault report it in writing. Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) I know a hospital in Metro Detroit that was offering it on their patient and guest WiFi in 2009. Of course, neither they, nor the individual running the rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was really screwing up access to my dual stacked hosts to be getting RAs on their wireless with no prefixes on them. I had to filter out RAs in iptables in order to effectively use their WiFi, which was a mess to begin with. The guilty party should remain nameless for google's sake, but if you're a netadmin in a largeish, three location hospital entirely in the detroit suburbs, say the largest inpatient hospital in the country, please make sure you either filter IPv6 or offer it yourself so you'll at least know if it's broken. As much as I hear people whining these days about how to handle rogue RAs, they don't seem to realize that this is ALREADY an issue on their network, even if they haven't, or won't adopt IPv6, and so this is a NOW problem either way and needs to be addressed. It's not a barrier to IPv6 adoption, it's a security threat right this minute. Either block protocol 0x86dd using a mac address prefix list, or traffic with a destination of 33:33:00:00:00:01 from all untrusted ports and you can now safely enable IPv6, OR just upgrade your gear, and while you're at it, you can now safely enable IPv6 anyway. -Paul
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On 2/5/2011 8:15 PM, Paul Timmins wrote: OR just upgrade your gear, and while you're at it, you can now safely enable IPv6 anyway. Well, enable IPv6. Safely? I don't see how upgrading your gear magically makes the various security threats -- including the current topic of rogue RAs -- go away. Matthew Kaufman
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On Feb 5, 2011, at 11:15 PM, Paul Timmins wrote: I know a hospital in Metro Detroit that was offering it on their patient and guest WiFi in 2009. Of course, neither they, nor the individual running the rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was really screwing up access to my dual stacked hosts to be getting RAs on their wireless with no prefixes on them. I had to filter out RAs in iptables in order to effectively use their WiFi, which was a mess to begin with. Wouldn't it have been awesome if, y'know, you hadn't had to worry about the RAs at all, but had just connected your single client machine, and gotten your simple gateway address from the DHCP server along with all the rest of your network configuration settings, just like has worked pretty darned well for a number of years? Oh, right... IPv6, whose mascot should be the camel[1]. Cheers, D [1] http://bit.ly/enLk3c
Re: Random Port Blocking at Hotels (was: Re: quietly....)
On Feb 5, 2011, at 8:30 PM, Matthew Kaufman wrote: On 2/5/2011 8:15 PM, Paul Timmins wrote: OR just upgrade your gear, and while you're at it, you can now safely enable IPv6 anyway. Well, enable IPv6. Safely? I don't see how upgrading your gear magically makes the various security threats -- including the current topic of rogue RAs -- go away. Matthew Kaufman Most rogue RAs are problematic on networks that don't have legitimate RAs to override them. Yes, someone can do a malicious RA, but, the current problem is mostly people doing accidental RAs thanks to Micr0$0ft's convenient Click here to screw your neighbors buttons. Owen
Re: Random Port Blocking at Hotels (was: Re: quietly....)
Derek J. Balling wrote: On Feb 5, 2011, at 11:15 PM, Paul Timmins wrote: I know a hospital in Metro Detroit that was offering it on their patient and guest WiFi in 2009. Of course, neither they, nor the individual running the rogue IPv6 router knew that, but as a person running an IPv6 enabled OS, it was really screwing up access to my dual stacked hosts to be getting RAs on their wireless with no prefixes on them. I had to filter out RAs in iptables in order to effectively use their WiFi, which was a mess to begin with. Wouldn't it have been awesome if, y'know, you hadn't had to worry about the RAs at all, but had just connected your single client machine, and gotten your simple gateway address from the DHCP server along with all the rest of your network configuration settings, just like has worked pretty darned well for a number of years? Because rogue DHCP servers have never been a problem. Switches supported keeping those secure since before DHCP was even commonly used, right? -Paul
Re: quietly....
In article 20110204000954.a64c79a9...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes These are just my straw poll of what may be difficult for small enterprises in a change to IPv6. It isn't change to, its add IPv6. I expect to see IPv4 used for years inside homes and enterprises where there is enough IPv4 addresses to meet the internal needs. It's external communication which needs to switch to IPv6. Internal communication just comes along for the ride. If people start supplying CPE that are running IPv6 on the outside and IPv4 NAT in the inside, then that would just fine, in the sense that the users (in this case including the self-administrators of these small enterprise networks) won't notice the difference. -- Roland Perry
Re: quietly....
On Feb 4, 2011, at 7:30 AM, Roland Perry wrote: It isn't change to, its add IPv6. I expect to see IPv4 used for years inside homes and enterprises where there is enough IPv4 addresses to meet the internal needs. It's external communication which needs to switch to IPv6. Internal communication just comes along for the ride. If people start supplying CPE that are running IPv6 on the outside and IPv4 NAT in the inside, then that would just fine, in the sense that the users (in this case including the self-administrators of these small enterprise networks) won't notice the difference. I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 record it gets from a DNS lookup? Sure, I think we're a long way off from any significant sites being v6-only, but 6-outside-4-inside CPE will cut those users off from 6-only sites unless the NATing CPE is also doing some really, really, wonky DNS interception and proxying at the same time, and I don't *anyone* wants to see that D
Re: quietly....
On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 record it gets from a DNS lookup? If the CPE is doing DNS proxy (most do) then it can map the record to an A record it passes to the internal client, with an internal address for the record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assigned RFC1918 address to the external IPv6 address from the record (since you have at least a /64 at your CPE, you can even use the RFC1918 address in the lower 32 bits :-P). This may already be a standard, or a draft, or implemented somewhere; I don't know. But that is how I would do it, just thinking off the top of my head.
Re: quietly....
On Thu, 03 Feb 2011 18:14:00 EST, david raistrick said: Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. It's client/server unless it's peer-to-peer is almost a tautology, you know... pgpxnPGpYgVwn.pgp Description: PGP signature
Re: quietly....
On Fri, Feb 4, 2011 at 11:38, valdis.kletni...@vt.edu wrote: On Thu, 03 Feb 2011 18:14:00 EST, david raistrick said: Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. It's client/server unless it's peer-to-peer is almost a tautology, you know... The argument is specious anyway, as many existing protocols that should by all rights be peer to peer, are forced to use HTTP to a server that someone has to pay for (and it isn't the guy running NAT) due to the brokenness of the internet. Those 65k ports were not meant solely for client random connects to port 80. Why an instant message client even would use the far over bloated HTTP to some 3rd party that shouldn't be privy to the packets anyway for the purpose is an example of what we've been reduced to. Trying to ask for examples of things that are broken by NAT or have not been implemented due to it, after it has been the standard for many years, and then using arguments that they work over NAT to counter it, ignoring the fact that someone had to invest a lot of money and time (again, not the NAT users) in being able to do that, is amazing to me. It's like asking for people that have died hungry to come speak out against hunger, and claiming that clearly it isn't a problem, when they don't show up. -Blake
Re: quietly....
On Thu, 3 Feb 2011, Owen DeLong wrote: Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. Largely because we've been living with the tradeoff that we had to break the end-to-end model to temporarily compensate for an address shortage. Those of us that remember life before NAT would prefer not to bring this damage forward into an area of address abundance. In other words, yes, we gave up Life before NAT, and firewalls (with or without SPI) on every PC and every CPI, also was life before mass consuption of internet access by the normal folks. And before extensive cellular and wifi networks for internet access. And before many of today's (common end user PC) security issues had been discovered. Firewalls -destroy- the end to end model. You don't get inbound connectivity past the firewall unless a rule is explicitly created. That's no different than NAT requiring specific work to be done. Firewalls are not going away, if anything the continuing expansion of consumer users will create more and more breakage of the open-everything-connects-to-everything model, regardless of what the core engineering teams may want. Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. The end-to-end model ended a long long time agomaybe it will come back, but I rather doubt it. We'll continue to have users, who run client software, and providers, who run server software. And a mix in between, because the user end can CHOOSE to enable server functionality (with their feet, by choosing a new ISP, at their firewall and or NAT device, and by enabling server software). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
On Feb 4, 2011, at 11:40 AM, Lamar Owen wrote: On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: I think they'll eventually notice a difference. How will an IPv4-only internal host know what to do with an IPv6 record it gets from a DNS lookup? If the CPE is doing DNS proxy (most do) then it can map the record to an A record it passes to the internal client, with an internal address for the record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assigned RFC1918 address to the external IPv6 address from the record (since you have at least a /64 at your CPE, you can even use the RFC1918 address in the lower 32 bits :-P). This may already be a standard, or a draft, or implemented somewhere; I don't know. But that is how I would do it, just thinking off the top of my head. That's exactly how I'd implement it too, but I'm just saying that that's sort of a kludge (even above and beyond the types of hoops that NAT itself is jumping through). You'd probably have to configure the CPE manually to say something like here's which RFC1918 space I *don't* care about, that you can use as your v6 IP NAT pool, so that the CPE didn't accidentally abuse IPs in use somewhere else in the environment D
RE: quietly....
snip Was TCP/IP this bad back in 1983, folks? Cheers, -- jra In different ways, yes, it was. Owen This is exactly the problem we have. Some people have no perspective on what the Internet is and it's real power. I've met too many people who claim to be in the know on these topics that don't understand that NAT was designed for address preservation. That was the only/primary/driving real reason for its development. The other features were side effects and are not intended to be solutions to production issues. If I use a wrench to hammer nails, it may work fine, but when It comes to certain nails it may have issues. I'm using the tool for the wrong purpose. This is the folly of NAT. - Brian J.
Re: quietly....
In message WQE8G0a2F$snf...@perry.co.uk, Roland Perry writes: In article 20110204000954.a64c79a9...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes These are just my straw poll of what may be difficult for small enterprises in a change to IPv6. It isn't change to, its add IPv6. I expect to see IPv4 used for years inside homes and enterprises where there is enough IPv4 addresses to meet the internal needs. It's external communication which needs to switch to IPv6. Internal communication just comes along for the ride. If people start supplying CPE that are running IPv6 on the outside and IPv4 NAT in the inside, then that would just fine, in the sense that the users (in this case including the self-administrators of these small enterprise networks) won't notice the difference. -- Roland Perry They exist are starting to exist and the feature sets keep expanding. I just wish that all vendors would stop shipping IPv4 only equipement. For example the D-LINK DIR-615 does just about everything upsteam except SLAAC which you want if you want to insert it into the middle of your network and not at the border. I havn't explictly asked D-LINK about SLAAC upstream but I couldn't find it in the manual. Newer firmware I believe does PD (again not in the manuals on the web). D-LINK claim they have routers that do 6rd. The DIR-615 is priced within a home budget but at the upper end. I was looking to buy one for home. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On Feb 4, 2011, at 4:32 PM, Mark Andrews wrote: In message 201102041140.42719.lo...@pari.edu, Lamar Owen writes: On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: I think they'll eventually notice a difference. How will an IPv4-only inter nal host know what to do with an IPv6 record it gets from a DNS lookup? If the CPE is doing DNS proxy (most do) then it can map the record to an A record it passes to the internal client, with an internal address for the record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from the assi gned RFC1918 address to the external IPv6 address from the record (since you have at least a /64 at your CPE, you can even use the RFC1918 address in the lower 32 bits :-P). This may already be a standard, or a draft, or implemented somewhere; I don't know. But that is how I would do it, just thinking off the top of my head. DS-lite delivers a IPv4 softwire over a IPv6 upstream. It also introduces less problems than NAT64 as it works with DNSSEC and with IPv4 literal. Along with DS-lite there is a UPNP replacement designed to work with distributed NATs (DS-Lite (AFTR+B4) and NAT444 (LSN + CPE NAT)) so that holes can be punched threw multiple devices if needed. I've yet to see a version of ALG that isn't buggy (eg: Cisco SIP-ALG, 2Wire/ATT uverse sip-alg is seriously broken, same for either dlink or netgear... we have to turn it off otherwise it does bad things). I'm sure that LSN activity is going to work great for the carriers. *shakes head* - jared
Re: quietly....
Semi-OT: You are now what we need you to be. A beaten, resentful people who will have to rebuild, who will have to rely on our.. good graces. Who can be used and.. guided as we wish to guide you. Perfect ground for us to do our work.. Quietly, quietly. Sorry.
Re: quietly....
In message alpine.bsf.2.00.1102041250570.54...@murf.icantclick.org, david rai strick writes: On Thu, 3 Feb 2011, Owen DeLong wrote: Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. Largely because we've been living with the tradeoff that we had to break th e end-to-end model to temporarily compensate for an address shortage. Those o f us that remember life before NAT would prefer not to bring this damage forward into an area of address abundance. In other words, yes, we gave up Life before NAT, and firewalls (with or without SPI) on every PC and every CPI, also was life before mass consuption of internet access by the normal folks. And before extensive cellular and wifi networks for internet access. And before many of today's (common end user PC) security issues had been discovered. Firewalls -destroy- the end to end model. You don't get inbound connectivity past the firewall unless a rule is explicitly created. That's no different than NAT requiring specific work to be done. No, they don't. end to end is about knowing how to reach everybody whether that is permitted or not. Firewalls are not going away, if anything the continuing expansion of consumer users will create more and more breakage of the open-everything-connects-to-everything model, regardless of what the core engineering teams may want. While it may be the default it should also be able to be turned off. CPE devices are not just uses at the edges of networks. The same boxes are used inside networks. Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. Some ISP's do lots of stupid things. The end-to-end model ended a long long time agomaybe it will come back, but I rather doubt it. We'll continue to have users, who run client software, and providers, who run server software. And a mix in between, because the user end can CHOOSE to enable server functionality (with their feet, by choosing a new ISP, at their firewall and or NAT device, and by enabling server software). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. Actually its a lot more difficult. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. Web browsers are much bigger security holes running arbitry code because some web page developer thought it would look nice. Most servers are written assuming the input stream is hostile. I run machines all the time that don't have firewall to protect them from the big wide world out there. I suspect we all do. Your not behind a external firewall when you are at NANOG or IETF. Everyone doesn't suddenly get owned because there isn't a external firewall. Modern OS's default to secure. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
In article f05d77a9631cae4097f7b69095f1b06f039...@ex02.drtel.lan, Brian Johnson bjohn...@drtel.com writes Some people have no perspective on what the Internet is and it's real power. I've met too many people who claim to be in the know on these topics that don't understand that NAT was designed for address preservation. Especially as most (I guess) users of NATing CPEs only have one dynamic IP address, of which they are generally oblivious. I have a feeling that the first NAT box I had (maybe 12 years ago), connected to the Internet by dial-up, where traditionally the user inherits the IP address (singular) of the modem/gateway they dialled into, even if they have multiple hosts on their premises. That was the only/primary/driving real reason for its development. The other features were side effects and are not intended to be solutions to production issues. But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once every five years like I just did with my ADSL, or once every time the new ADSL hiccups[1] now that I have a CPE with 3G failover. [1] Seems to be about weekly, so far. -- Roland Perry
Re: quietly....
Everyone doesn't suddenly get owned because there isn't a external firewall. Modern OS's default to secure. We clearly live and work in different worlds. Not to mention that we are not the average consumers anymore. We were, in the days before NAT (and SPI). -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
On Fri, 4 Feb 2011, Roland Perry wrote: But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once But (what I keep being told) you should never have to renumber! Get PI space and insert magic here! sigh -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: quietly....
david raistrick wrote: Everyone doesn't suddenly get owned because there isn't a external firewall. Modern OS's default to secure. We clearly live and work in different worlds. Not to mention that we are not the average consumers anymore. We were, in the days before NAT (and SPI). A quick mental review of my relatives indicates more than a few of them with a PC jacked into a cable modem. The only firewall is the one that comes with Windows. Sure, pretty much every company and +some+ residential service has a firewall fo some sort in place, but they aren't the automatic default that you are assuming. As you say, live and work in different worlds. Reto -- R A Lichtensteiger r...@tifosi.com A polar bear is just another way of expressing a rectangular bear
Re: quietly....
In message fe7943df-6a3a-478f-af40-de4d3592f...@puck.nether.net, Jared Mauch writes: On Feb 4, 2011, at 4:32 PM, Mark Andrews wrote: =20 In message 201102041140.42719.lo...@pari.edu, Lamar Owen writes: On Friday, February 04, 2011 09:05:09 am Derek J. Balling wrote: I think they'll eventually notice a difference. How will an = IPv4-only inter nal host know what to do with an IPv6 record it gets from a DNS = lookup? =20 If the CPE is doing DNS proxy (most do) then it can map the = record to an A record it passes to the internal client, with an internal address = for the=20 record chosen from RFC1918 space, and perform IPv4-IPv6 1:1 NAT from = the assi gned RFC1918 address to the external IPv6 address from the = record (since you have at least a /64 at your CPE, you can even use the RFC1918 = address in the lower 32 bits :-P). =20 =20 This may already be a standard, or a draft, or implemented somewhere; = I don't know. But that is how I would do it, just thinking off the top of my = head. =20 =20 DS-lite delivers a IPv4 softwire over a IPv6 upstream. It also introduces less problems than NAT64 as it works with DNSSEC and with IPv4 literal. Along with DS-lite there is a UPNP replacement designed to work with distributed NATs (DS-Lite (AFTR+B4) and NAT444 (LSN + CPE NAT)) so that holes can be punched threw multiple devices if needed. I've yet to see a version of ALG that isn't buggy (eg: Cisco SIP-ALG, = 2Wire/ATT uverse sip-alg is seriously broken, same for either dlink or = netgear... we have to turn it off otherwise it does bad things). And you reported the bugs. I'm sure that LSN activity is going to work great for the carriers. Yes it is a worry which is why we want people to move to IPv6 and not use NAT. Less things to go wrong. A firewall only has to react to the traffic not re-write it. One lesa thing to go wrong. - jared= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
In message clgjgqw4yhtnf...@perry.co.uk, Roland Perry writes: But NAT does have the useful (I think) side effect that I don't have to renumber my network when I change upstream providers - whether that's once every five years like I just did with my ADSL, or once every time the new ADSL hiccups[1] now that I have a CPE with 3G failover. [1] Seems to be about weekly, so far. -- Roland Perry And that can be pretty much automated these days. Windows boxes if you let them will just register their new addresses in the DNS. MacOS also has the ability to do this as well. You should be asking the other vendors for similar support. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On 2/4/11 2:34 PM, R A Lichtensteiger wrote: david raistrick wrote: Everyone doesn't suddenly get owned because there isn't a external firewall. Modern OS's default to secure. We clearly live and work in different worlds. Not to mention that we are not the average consumers anymore. We were, in the days before NAT (and SPI). A quick mental review of my relatives indicates more than a few of them with a PC jacked into a cable modem. The only firewall is the one that comes with Windows. Sure, pretty much every company and +some+ residential service has a firewall fo some sort in place, but they aren't the automatic default that you are assuming. As you say, live and work in different worlds. Bearing in mind that modst of the computers being sold today are laptops they do not sit inside the home cowering behind the firewall they are routinely attached to all sorts of potentially hositile environments, campus networks, offices, starbucks, airplanes etc and the only security perimeter they can count on is the one established inside the network interface rather than outside of it. this mac while a little more widely traveled than most has 500+ wireless networks which it remembers. making assumptions abou the security of the nework outside your machine or expectations for it is extremely dangerous. mMving into the future a larger percentage of the devices are or are going to be network agile and the upshot is a rather different take on what constitutes a security domain. Reto
Re: quietly....
On Feb 4, 2011, at 10:04 AM, david raistrick wrote: On Thu, 3 Feb 2011, Owen DeLong wrote: Er. That's not news. That's been the state of the art for what, 15+ years or so now? SIP (because it's peer to peer) and P2P are really the only things that actually give a damn about it. Largely because we've been living with the tradeoff that we had to break the end-to-end model to temporarily compensate for an address shortage. Those of us that remember life before NAT would prefer not to bring this damage forward into an area of address abundance. In other words, yes, we gave up Life before NAT, and firewalls (with or without SPI) on every PC and every CPI, also was life before mass consuption of internet access by the normal folks. And before extensive cellular and wifi networks for internet access. And before many of today's (common end user PC) security issues had been discovered. Firewalls -destroy- the end to end model. You don't get inbound connectivity past the firewall unless a rule is explicitly created. That's no different than NAT requiring specific work to be done. No... Firewalls enforce policies on the end-to-end connectivity. The end-to-end model is not about every host can deliver a packet to every other host. That is a misunderstanding of the meaning and principle of the end-to-end model. The end-to-end model is about If my packet is permitted by policy and delivered to the remote host, I expect it to arrive as sent, without unexpected modifications. Mutilating the IP address portion of the header is an unexpected modification. Decrementing the TTL and replacing the MAC address for routing are not unexpected modifications. Firewalls are not going away, if anything the continuing expansion of consumer users will create more and more breakage of the open-everything-connects-to-everything model, regardless of what the core engineering teams may want. Nobody wants to get rid of firewalls. We want to get rid of NAT. Firewalls work great without NAT and by having firewalls without NAT, we gain back the end-to-end model while preserving the ability to enforce policy on end-to-end connectivity. Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. Really? And they have subscribers? Surprising. The end-to-end model ended a long long time agomaybe it will come back, but I rather doubt it. Sadly, yes. We gave up the end-to-end model when we accepted NAT as a workaround for address shortage. We did so believing that IPv6 deployment and migration would eventually remove this shortage (which it does) and allow us to restore the end-to-end model. Now you're suggesting we should abandon that hope? I think not. We'll continue to have users, who run client software, and providers, who run server software. And a mix in between, because the user end can CHOOSE to enable server functionality (with their feet, by choosing a new ISP, at their firewall and or NAT device, and by enabling server software). There is no need for NAT. NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. NAT does destroy end-to-end. Firewalls do not. Owen
Re: quietly....
On 2/4/2011 6:27 PM, Owen DeLong wrote: Hell, even without CPE doing it, many residential ISPs (regardless of NAT) block inbound traffic to consumers. Really? And they have subscribers? Surprising. Mark Andrews wrote: I run machines all the time that don't have firewall to protect them from the big wide world out there. I suspect we all do. Your not behind a external firewall when you are at NANOG or IETF. Everyone doesn't suddenly get owned because there isn't a external firewall. Modern OS's default to secure. Yes, and some of you thanked us for blocking RPC in the ISP or in the cable modems. Many such blocks are still in place in many ISPs as there was no reason to ever remove them. TCP/25 outbound is often blocked in many locations as well. Just because you don't notice the firewall, doesn't mean it doesn't exist. We stay in business when you don't notice. :) Jack
Re: quietly....
Original Message - From: Brian Johnson bjohn...@drtel.com This is exactly the problem we have. Some people have no perspective on what the Internet is and it's real power. I've met too many people who claim to be in the know on these topics that don't understand that NAT was designed for address preservation. That was the only/primary/driving real reason for its development. The other features were side effects and are not intended to be solutions to production issues. [were] not intended to be solutions to production issues != are not being depended on now. If I use a wrench to hammer nails, it may work fine, but when It comes to certain nails it may have issues. I'm using the tool for the wrong purpose. This is the folly of NAT. Perhaps. But that's not important, now. Cheers, -- jr 'Good luck. We're all counting on you' a
Re: quietly....
On Feb 4, 2011, at 6:23 PM, Jay Ashworth wrote: Original Message - From: Brian Johnson bjohn...@drtel.com This is exactly the problem we have. Some people have no perspective on what the Internet is and it's real power. I've met too many people who claim to be in the know on these topics that don't understand that NAT was designed for address preservation. That was the only/primary/driving real reason for its development. The other features were side effects and are not intended to be solutions to production issues. [were] not intended to be solutions to production issues != are not being depended on now. If I use a wrench to hammer nails, it may work fine, but when It comes to certain nails it may have issues. I'm using the tool for the wrong purpose. This is the folly of NAT. Perhaps. But that's not important, now. Cheers, -- jr 'Good luck. We're all counting on you' a True. It's also a backwards version of the analogy. The IPv4 situation today is that we have very few screws and we use NAT as a hammer to pound in small brads in places where we need screws because they are the only fastener we have left. What is important with IPv6 is to teach the generation of hammer-wielding mechanics who have grown up rarely seeing a screw and never knowing that there were wrenches that there are new tools available in IPv6. That screws or nuts and bolts can usually be superior to nails. That screws, nuts, and bolts work better if you install them with a screw driver or a wrench. That small brads lack structural integrity and that lag screws or bolts provide a superior structural hold when installed properly. That attempting to hammer every screw into a NAT-hole will destroy both the screw and the NAT-hole in most cases. Owen
Re: quietly....
On 2/4/2011 8:05 PM, Owen DeLong wrote: True... If you review the NANOG archives you'll find that at least in the case of the port 25 absurdity, I have noticed and have railed against it. Yeah, I threw it in as an afterthought. ISP firewalls do exist and not just small isolated incidents. I wish more money had gone into making them much more adaptive, then you could enjoy your tcp/25 and possibly not have a problem unless your traffic patterns drew concerns and caused an adaptive filter to block it (eh? thousands of emails suddenly to a variety of servers? block). Interestingly, adaptive filters are often used for probing scans (and we didn't apply them to tcp/25, why?) Jack
RE: quietly....
Yeah, I threw it in as an afterthought. ISP firewalls do exist and not just small isolated incidents. I wish more money had gone into making them much more adaptive, then you could enjoy your tcp/25 and possibly not have a problem unless your traffic patterns drew concerns and caused an adaptive filter to block it (eh? thousands of emails suddenly to a variety of servers? block). Interestingly, adaptive filters are often used for probing scans (and we didn't apply them to tcp/25, why?) Jack Maybe because it is just easier to do a transparent redirect to the ISPs mail server and look for patterns there. Some customer drops a bazillion email messages from a bazillion From: addresses in 14.7 seconds ... chances are you have a spam candidate. If the spam filter flags a lot (all?) of the messages as possible spam, queue them to the quarantine until someone can have a look and if they are, dismiss the customer and send them up the road OR inform them that they are possibly bot-net infected and block access to port 25 from them until they get it cleaned up.
Re: quietly....
On 2/4/2011 9:25 PM, George Bonser wrote: Maybe because it is just easier to do a transparent redirect to the ISPs mail server and look for patterns there. Analyzing flows generally isn't any more difficult than analyzing mail log patterns. It doesn't have the queue and check mechanism of a transparent redirect, but transparent redirects break certain types of mail connections as well. It is good practice for an ISP to run flow analysis anyways to detect bad traffic patterns. What I really want and haven't had time to write is a good procedure that establishes dynamic policies for flow pattern matches which causes the suspect packets to start tag switching to an analysis server where it is closer examined before actual filters are updated. I'd really like to see standards developed which router vendors supported to make such dynamic policies easier to update, along with the filters themselves. Perhaps we'll see it after more pressing IPv6 concerns are addressed. Jack
Re: quietly....
On Feb 4, 2011, at 6:53 PM, Jack Bates wrote: On 2/4/2011 8:05 PM, Owen DeLong wrote: True... If you review the NANOG archives you'll find that at least in the case of the port 25 absurdity, I have noticed and have railed against it. Yeah, I threw it in as an afterthought. ISP firewalls do exist and not just small isolated incidents. I wish more money had gone into making them much more adaptive, then you could enjoy your tcp/25 and possibly not have a problem unless your traffic patterns drew concerns and caused an adaptive filter to block it (eh? thousands of emails suddenly to a variety of servers? block). Interestingly, adaptive filters are often used for probing scans (and we didn't apply them to tcp/25, why?) Jack Sad, but true. I will not patronize an ISP that decides for me which packets I want and do not want, but, apparently there are people who will. Not sure how I feel about a more adaptive version. Sounds like it would be better than the current state, but, I vastly prefer I pay, you route. If I want filtration, I'll tell you. Owen
Re: quietly....
On Feb 4, 2011, at 7:25 PM, George Bonser wrote: Yeah, I threw it in as an afterthought. ISP firewalls do exist and not just small isolated incidents. I wish more money had gone into making them much more adaptive, then you could enjoy your tcp/25 and possibly not have a problem unless your traffic patterns drew concerns and caused an adaptive filter to block it (eh? thousands of emails suddenly to a variety of servers? block). Interestingly, adaptive filters are often used for probing scans (and we didn't apply them to tcp/25, why?) Jack Maybe because it is just easier to do a transparent redirect to the ISPs mail server and look for patterns there. Some customer drops a bazillion email messages from a bazillion From: addresses in 14.7 seconds ... chances are you have a spam candidate. If the spam filter flags a lot (all?) of the messages as possible spam, queue them to the quarantine until someone can have a look and if they are, dismiss the customer and send them up the road OR inform them that they are possibly bot-net infected and block access to port 25 from them until they get it cleaned up. The problem is some providers get a little too zealous and not only break port 25 (which is just mildly annoying), but, also break 587 and in rare cases 465 as well. Since I use SMTP+TLS to connect back to my mail server and use STMPAUTH to send my mail, hotels and conference centers that do this prove to be an annoying hurdle to doing something useful. The worst one I encountered was a JetStar lunch in Adelaide. They not only blocked 25, 465, 587, etc. They blocked everything except 80 and 443. I resorted to using an SSH client on my iPad over 3G to log into my server and start an SSH daemon on port 443 on an additional IP address I assigned. After that, I was able to use SSH tunnels for everything else. I don't know what a less technical user would to do use their lounge to actually use the internet. Just one more item in a long list of reasons I will _NEVER_ do business with JetStar again and will avoid Qantas unless I have no choice (since they own JetStar). Owen
Re: quietly....
On Wed, 2 Feb 2011, Tony Finch wrote: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: Example: if you give administrators the option of putting a router address in a DHCP option, they will do so and some fraction of the time, this will be the wrong address and things don't work. If you let routers announce their presence, then it's virtually impossible that something goes wrong because routers know who they are. A clear win. Counterexample: rogue RAs from Windows boxes running 6to4 or Teredo and Internet Connection Sharing. This is a lot harder to fix than a misconfigured DHCP server. http://malc.org.uk/6doom Force your switch vendor to implement rogue RA filter (ra guard) in your box: http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard Best Regards, Janos Mohacsi
Re: quietly....
Just need to add default route in there and make dhcpd do RA then the user can turn off RA on their routers and not care that DHCPv6 doesn't include default router. Having a DHCP server generate RA messages kind of defeats the point of having RA messages in the first place, resulting in loss of robustness, and now a new mode of failure. We've already established that the people who want a complete dhcpv6 do not care, they are going to maintain their dhcp server as much as their router, they are equally robust to the same degree of arm waving that the router is robust. That this is still being asked for in dhcp should be enough to convince people IETF RA is all you'll ever need mind tricks aren't going to make them go away. I say they as I work on both sides. I know today we have to work with what's been specced though we can choose how to implement them and continue to raise the issues for future development rather than let them be swept aside. brandon
IPv6 routing talk @ RIPE, was: Re: quietly....
On 2 feb 2011, at 23:40, Lamar Owen wrote: I can explain everything you need to know about how to run IPv6 BGP, RIP and OSPF in an hour and a half. Did that at a RIPE meeting some years ago. Setting up Apache to use IPv6 is one line of config. BIND two or three (not counting IPv6 reverse zones). Now, taking the op hat off for a moment, and stepping down from the soapbox, this is something that could be useful; has this talk been recorded and/or transcribed? If so, that's a useful resource, and, an hour and a half of relevant material is much easier to swallow than some of the books out there. Yes, they recorded it (but in pretty low quality and they didn't bother to cut out the many minutes during which we tried to get the projector and my laptop to talk to each other). It's linked at the top of this page: http://www.ripe.net/ripe/meetings/ripe-53/presentations/wednesday.html These are the slides: http://www.bgpexpert.com/presentations/ipv6_tutorial.pdf
Re: quietly....
Some applications will still require ALG functionality (or modification) to manage the state in the stateful firewall. This is where I think the end to end mantra has lead us astray. The users do not care, they just want stuff to work despite security and other real world complexities that have been handled with ALG, SPF and NAT (I agree NAT as bodged on v4 is evil) There might be some additional signaling required between the host and the firewall in order to let the firewall know If v6 had allowed for indirect end to end, such as with SOCKS, then people who want ALG, SPF, NAT could do them without having to infer intent and end up breaking apps. brandon
Re: quietly....
On Feb 2, 2011, at 11:47 PM, Jimmy Hess wrote: Having a DHCP server generate RA messages kind of defeats the point of having RA messages in the first place, resulting in loss of robustness, and now a new mode of failure. And by new here you mean exactly the same mode of failure that's been around for decades but hasn't been so serious as to be the downfall of internetworking. Right?
Re: quietly....
On Wed, Feb 02, 2011 at 08:22:34PM -0500, Randy Carpenter wrote: End user, a /48 will cost you $1,250 one-time and then it's part of your usual $100/year that you would be paying if you had an ASN or IPv4 space anyway. Any reason why RIPE NCC charges so much more? http://www.ripe.net/membership/billing/procedure-enduser.html (other than because they can, I mean). Owen And, even if you are an ISP, you only pay the larger of the two fees if you have both v4 and v6. I'm not sure if that is permanent or not, though. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Re: quietly....
On 03/02/2011 12:49, Eugen Leitl wrote: Any reason why RIPE NCC charges so much more? http://www.ripe.net/membership/billing/procedure-enduser.html (other than because they can, I mean). That's if you deal with the RIPE NCC directly. If you get your direct assignments via a LIR, the cost drops to €50 per each independent number resource, with no setup fee. Although a wholesale cost, it is significantly cheaper than ARIN. Nick
RE: quietly....
I don't mean to rain on your parade here...oh wait, yeah, I do actually. I have an SGI Indigo (MIPS R3000/25 with 32MB RAM baby, it's a screamer!) that still runs with no problems. Show me an eighteen year old router that's still up and running. The Dell hardware we ran NT4 Server on for providing DHCP until I replaced it is still as functional today as it was when it was purchased in 1998. I have a five year old Cisco doorstop. Don't tell me routers are made of magic hardware that is somehow immune to failure. Jamie -Original Message- From: Jimmy Hess [mailto:mysi...@gmail.com] Sent: Wednesday, February 02, 2011 11:48 PM To: Brandon Butterworth Cc: nanog@nanog.org Subject: Re: quietly On Wed, Feb 2, 2011 at 7:10 PM, Brandon Butterworth bran...@rd.bbc.co.uk wrote: Just need to add default route in there and make dhcpd do RA then the user can turn off RA on their routers and not care that DHCPv6 doesn't include default router. Having a DHCP server generate RA messages kind of defeats the point of having RA messages in the first place, resulting in loss of robustness, and now a new mode of failure. The point of having RA messages is they are simple, and integrated into the routers, so there is not a separate server to fail (a DHCP server) to cause loss of connectivity, due to server appliances (computers) being less reliable than routers. With the RA integrated into the routers properly, clients can maintain connectivity (and establish connectivity, provided DNS details obtained in the past), even if DHCP server(s) should fail. -- -JH
Re: quietly....
* Nick Hilliard: On 03/02/2011 12:49, Eugen Leitl wrote: Any reason why RIPE NCC charges so much more? http://www.ripe.net/membership/billing/procedure-enduser.html (other than because they can, I mean). That's if you deal with the RIPE NCC directly. If you get your direct assignments via a LIR, the cost drops to €50 per each independent number resource, with no setup fee. Although a wholesale cost, it is significantly cheaper than ARIN. Has RIPE charged a LIR for their independent resources yet? I don't think so. Therefore, comparisons with ARIN are a bit premature. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
