039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED ... whimper ...
That was it :-) so long IPv4! It's been a great ride! As good old Frank said, "And now, the end is near, we face the final curtain..." cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy@psg.com> wrote:
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder.
randy
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
I thought there are still 5 /8's left in IANA. -----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly.... That was it :-) so long IPv4! It's been a great ride! As good old Frank said, "And now, the end is near, we face the final curtain..." cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy@psg.com> wrote:
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder.
randy
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
I seem to recall there is an automatic endgame for those...? On Mon, Jan 31, 2011 at 7:20 PM, Patrick Greene <patrickg@layer8llc.com>wrote:
I thought there are still 5 /8's left in IANA.
-----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly....
That was it :-) so long IPv4! It's been a great ride!
As good old Frank said, "And now, the end is near, we face the final curtain..."
cheers!
Carlos
On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy@psg.com> wrote:
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder.
randy
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On Mon, Jan 31, 2011 at 4:22 PM, Jack Bates <jbates@brightok.net> wrote:
On 1/31/2011 6:20 PM, Patrick Greene wrote:
I thought there are still 5 /8's left in IANA.
I thought there was an agreement that when there was only 5 /8's, each RIR would be allocated 1 /8, and IANA would be done. :)
Jack
It's more than just an agreement--it's part of the documented IANA global policy: http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm We're now faction section 2 action. Matt
One each of the remaining /8′s will be allocated to each RIR. Once the RIR’s are out of space in their current supply and they only have this 1 /8 left, it will trigger policies relating to how that /8 will be allocated. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net<mailto:skeeve@eintellego.net> / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. On 1/02/11 11:20 AM, "Patrick Greene" <patrickg@layer8llc.com<mailto:patrickg@layer8llc.com>> wrote: I thought there are still 5 /8's left in IANA. -----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly.... That was it :-) so long IPv4! It's been a great ride! As good old Frank said, "And now, the end is near, we face the final curtain..." cheers! Carlos On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote: 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder. randy -- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
The last 5 are, by existing agreement, to be allocated 1 per Regional registry immediately after the other /8s are exhausted. This was agreed to some time ago to ensure that no regional was disadvantaged by timing concerns on applications for space as the IANA exhaustion approached. As that has now happened, all that awaits is for the announcement of which RIR got which remaining /8. "Immediate" doesn't mean today this instant, but by agreement, they're effectively all gone right now. The large woman has walked on stage and is awaiting the orchestra director's starting the music. -george On Mon, Jan 31, 2011 at 4:20 PM, Patrick Greene <patrickg@layer8llc.com> wrote:
I thought there are still 5 /8's left in IANA.
-----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly....
That was it :-) so long IPv4! It's been a great ride!
As good old Frank said, "And now, the end is near, we face the final curtain..."
cheers!
Carlos
On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy@psg.com> wrote:
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder.
randy
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
-- -george william herbert george.herbert@gmail.com
They are effectively gone, will be allocated in coming days or weeks, 1 per RIR. This is per global IANA policy. regards Carlos On 1/31/11 10:20 PM, Patrick Greene wrote:
I thought there are still 5 /8's left in IANA.
-----Original Message----- From: Carlos Martinez-Cagnazzo [mailto:carlosm3011@gmail.com] Sent: Monday, January 31, 2011 4:36 PM To: NANOG Subject: Re: quietly....
That was it :-) so long IPv4! It's been a great ride!
As good old Frank said, "And now, the end is near, we face the final curtain..."
cheers!
Carlos
On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush <randy@psg.com> wrote:
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED it's been on most of the lists. sunny will probably post to nanog shortly. the announcement is really well phrased, but i will not steal sunny's thunder.
randy
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
On Mon, Jan 31, 2011 at 5:36 PM, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
That was it :-) so long IPv4! It's been a great ride!
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride. There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
As good old Frank said, "And now, the end is near, we face the final curtain..."
-- -JH
On 1/31/2011 9:55 PM, Jimmy Hess wrote:
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
Until the core networks fix their peering relationships, I don't think it matters. My connectivity to google still sucks. Nothing else matters. :) Jack
On Jan 31, 2011, at 7:55 PM, Jimmy Hess wrote:
On Mon, Jan 31, 2011 at 5:36 PM, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
That was it :-) so long IPv4! It's been a great ride!
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
As good old Frank said, "And now, the end is near, we face the final curtain..."
-- -JH
It may not be dead, but, it's is chain stoking. Owen
On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia@gmail.com> wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up! -Jack Carrozzo
On Jan 31, 2011, at 8:15 PM, Jack Carrozzo wrote:
On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia@gmail.com> wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up!
-Jack Carrozzo
All of the eye networks that have looked at this have realized the following things that you apparently have not: 1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. 2. NAT444 will break lots of things that work in current NAT44. 3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. 5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative. Owen
On 1/31/2011 10:29 PM, Owen DeLong wrote:
1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. yep
2. NAT444 will break lots of things that work in current NAT44.
To be honest, ds-lite, despite being single layer still breaks most things that a NAT44 with upnp won't.
3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. Neither would an engineer, which is why we have real IPs at our house. :) 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. Even maintaining dual stack is costly. NAT444 just makes it worse.
5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative.
Yep. Once the NSPs get their stuff done and we have decent routing paths, the eyeballs will either already be done or quickly behind them, and then the content can start switching over without the fears they currently have. Jack
On Feb 1, 2011, at 9:50 AM, Jack Bates wrote:
On 1/31/2011 10:29 PM, Owen DeLong wrote:
1. Layering NAT beyond 2 deep (one provider, one subscriber) doesn't help. yep
2. NAT444 will break lots of things that work in current NAT44.
To be honest, ds-lite, despite being single layer still breaks most things that a NAT44 with upnp won't.
3. Users subjected to this environment after experiencing the limited brokenness of NAT44 or full access to the internet will not be happy. Neither would an engineer, which is why we have real IPs at our house. :) 4. Maintaining NAT444 environments will be a support headache and a costly arms race of deployments and management. Even maintaining dual stack is costly. NAT444 just makes it worse.
5. IPv6 will cost a lot less than NAT444 as soon as they can get their subscribers fully deployed and is a much more desirable alternative.
Yep. Once the NSPs get their stuff done and we have decent routing paths, the eyeballs will either already be done or quickly behind them, and then the content can start switching over without the fears they currently have.
Honestly, if you can't get native wholesale IP, you are buying from the wrong carriers. - Jared
On 2/1/2011 8:53 AM, Jared Mauch wrote:
Honestly, if you can't get native wholesale IP, you are buying from the wrong carriers.
I agree. I did up the $5 million budget to light dwdm ring with 8x10GE to Dallas where I could connect to any provider I wanted, but it was unfortunately declined. However, that's not the point. The point is that IPv6 routing paths through the largest networks are not the same as IPv4 routing paths. There are still many unoptimized routes and even a lack of peering. General latency and bandwidth availability for IPv6 is a QOS nightmare compared to IPv4. The weirdest one I came across is that, at one point, I had the best connectivity with limelight (for netflix streams) by sending packets out L3, and having them return via a HE tunnel. It was, of course, well below IPv4 standards. Jack
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here) -Jeremy On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo <jack@crepinc.com> wrote:
On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia@gmail.com> wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up!
-Jack Carrozzo
On Mon, 31 Jan 2011, Jeremy wrote:
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here)
I think it has been discussed at various levels, but would likely have been dismissed for one or more of the following reasons: 1. A lot of people filter packets and/or prefixes 224/3 or 240/4 out of habit, right, wrong, or otherwise, so space from 240/4 is likely to have lots of reachability problems. 2. The effort expended by people to solve reachability problems from space they'd get out of 240/4 would be better put toward moving to v6. 3. Busting out 16 more /8s only delays the IPv4 endgame by about a year. jms
On Jan 31, 2011, at 4:49 PM, Justin M. Streiner wrote:
On Mon, 31 Jan 2011, Jeremy wrote:
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here)
I think it has been discussed at various levels, but would likely have been dismissed for one or more of the following reasons: 1. A lot of people filter packets and/or prefixes 224/3 or 240/4 out of habit, right, wrong, or otherwise, so space from 240/4 is likely to have lots of reachability problems.
Also, many systems will not accept this traffic or configuration as hard-coded system parameters.
2. The effort expended by people to solve reachability problems from space they'd get out of 240/4 would be better put toward moving to v6.
Not to mention the software updates required to make it functional would exceed the software updates necessary for IPv6 _AND_ it has no lasting future.
3. Busting out 16 more /8s only delays the IPv4 endgame by about a year.
Actually, if last year's consumption is any indicator, it's more like 10 months and given the accelerating consumption of IPv4 overall, I'd say less than 9 is not unlikely. I'm betting you're talking about more than 9 months to get the software and reachability issues resolved. Owen
Not to mention the software updates required to make it functional would exceed the software updates necessary for IPv6 _AND_ it has no lasting future.
Part one of that statement goes for v6 in a lot of places. The whole NAT444 allocation argument would go away with this. Maybe we need both. It might be easier to teach a v4-only device to use that space than to teach it to use v6. Part 2 is dead on in that it has no "lasting future" ... but what if it does? What if "Outer Slobovia" decides to simply number their nation using the entire v4 /0. Everyone can talk with each other inside the country just fine. $PROVIDER wants to provide services there? Well, they will just need to get an allocation out of Outer Slobovia's address space and NAT that to their services using either NAT44 or a stateless NAT64/DNS64 (Tayga or something). Outer Slobovia gets mad at the world? They just black hole the block set aside for foreign assignments and connectivity is instantly cut off. No v6 and no v4 leaks outside the country. I suspect we will see countries do just that.
3. Busting out 16 more /8s only delays the IPv4 endgame by about a year.
jms
If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it.
On 1/31/11 10:43 PM, George Bonser wrote:
3. Busting out 16 more /8s only delays the IPv4 endgame by about a year.
jms
If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it.
except when the tried to determine their external ip. and of course one of the big applications for cgnat is mobile where the cpe are the end systems... There are negligible benefits as far as I can tell from the vantage points of end systems to creating new private scope ipv4 regions at this late date. network operators see some but frankly each one comes with additional support costs as does using rfc1918... the difference is we've got a lot of experience with the latter even in nat444 envirnments.
There are negligible benefits as far as I can tell from the vantage points of end systems to creating new private scope ipv4 regions at this late date.
Here, yes. In other places, maybe there are other factors. I am not saying I favor such a thing, just going through the exercise of thinking through how to deal with one when/if it appears and recognizing that such a thing could happen. Imagine The Repressive Republic of Slobovia wants to absolutely control who talks to whom over that country's internet infrastructure (or, more accurately, who doesn't talk to whom). That is a fairly easy way of doing it. They absolutely control the entire addressing spectrum and if desired, nothing leaks. Now that isn't to say people don't find ways out, as they always will.
On Jan 31, 2011, at 11:41 PM, George Bonser wrote:
There are negligible benefits as far as I can tell from the vantage points of end systems to creating new private scope ipv4 regions at this late date.
Here, yes. In other places, maybe there are other factors. I am not saying I favor such a thing, just going through the exercise of thinking through how to deal with one when/if it appears and recognizing that such a thing could happen.
Imagine The Repressive Republic of Slobovia wants to absolutely control who talks to whom over that country's internet infrastructure (or, more accurately, who doesn't talk to whom). That is a fairly easy way of doing it. They absolutely control the entire addressing spectrum and if desired, nothing leaks. Now that isn't to say people don't find ways out, as they always will.
That's a really good reason NOT to provide this ability. There's no advantage to the global internet for facilitating such a thing. Owen
On Jan 31, 2011, at 10:43 PM, George Bonser wrote:
3. Busting out 16 more /8s only delays the IPv4 endgame by about a year.
jms
If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it.
If they could do code updates on the CPE, then, they could use RFC-1918. The problem is that code-updating that much CPE is, well, impractical to say the least. Owen
I think the ship has sailed for the class E /8s. Using them will require significant effort and that effort, both time and money, is better spent on deploying IPv6. regards Carlos On 2/1/11 9:45 AM, Owen DeLong wrote:
On Jan 31, 2011, at 10:43 PM, George Bonser wrote:
3. Busting out 16 more /8s only delays the IPv4 endgame by about a year.
jms If used for general assignment, sure. But if used for what people have been begging for NAT444 middle-4 space. Well, that might work. Code update on the CPE is all it would take. The systems involved would never see it.
If they could do code updates on the CPE, then, they could use RFC-1918.
The problem is that code-updating that much CPE is, well, impractical to say the least.
Owen
Discussed, Disgusted, and Dismissed. The E space would take more software upgrades to existing systems than just deploying IPv6. Owen On Jan 31, 2011, at 8:31 PM, Jeremy wrote:
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here)
-Jeremy
On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo <jack@crepinc.com> wrote:
On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia@gmail.com> wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up!
-Jack Carrozzo
On Mon, Jan 31, 2011 at 8:38 PM, Owen DeLong <owen@delong.com> wrote:
Discussed, Disgusted, and Dismissed.
The E space would take more software upgrades to existing systems than just deploying IPv6.
It's true. It was only after discovering how much work it would take to make 240/4 like RFC 1918 (truly impossible) that I fully engaged in doing IPv6. Now, we are pretty close to launching an IPv6-only + NAT64 service to mobile customer. Cameron =========================== T-Mobile USA IPv6 Beta -> http://bit.ly/9s0Ed3 ===========================
Jeremy, I have not heard of any IP stack that is built to accept 240/4. Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there. The logic goes: You are many orders of magnitudes more likely to get v6 off the ground, than 240/4 or 224/4 as unicast IPv4. 224/3 will never be very usable as public v4 space since every non-upgraded host on the Internet will be unable to send packets to them, eg, for every additional host you introduce with these addresses the worse the reachability situation becomes for the v4 Internet. Notably, this is the inverse of what happens when you introduce more hosts with native, proper IPv6, in the IPv6-Internet. Cheers, Martin On Mon, Jan 31, 2011 at 11:31 PM, Jeremy <jbaino@gmail.com> wrote:
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here)
-Jeremy
On Mon, Jan 31, 2011 at 10:15 PM, Jack Carrozzo <jack@crepinc.com> wrote:
On Mon, Jan 31, 2011 at 9:55 PM, Jimmy Hess <mysidia@gmail.com> wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
There is some hope more IPv4 organizations will start thinking about their plans for establishing connectivity with IPv6; so they can commmunicate with IPv6-only hosts that will begin to emerge later.
What organizations (eye networks) will do is layer NAT till the cows come home for some years to come. Buckle up!
-Jack Carrozzo
On Tue, Feb 1, 2011 at 12:00 AM, Martin Millnert <millnert@gmail.com> wrote:
Neither Linux 2.6.37 nor Windows 7 accepts it
Oops, I was clumpsy there, apologies. When I was testing this, I messed up one of my hosts :/ It seems 240/4 *does* work as unicast v4 in Linux 2.6.37. Then it's easy, just convert everything to Linux. ;) /M
On Mon, Jan 31, 2011 at 11:00 PM, Martin Millnert <millnert@gmail.com> wrote: This has come up before, in 2007, and earlier, http://www.merit.edu/mail.archives/nanog/2007-10/msg00487.html Way too late now for unreserving 240/4 to help. Now, if it had been unreserved in 2003 or so, there might not be so many devices to upgrade. There could a case to be made for unreserving 240/4 now, so perhaps it could be used in 2020,.
Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there.
hm...... for Linux, there was a patch for this in 2008, in the kernel proper should be in 2.6.25 and newer, http://kerneltrap.org/mailarchive/linux-netdev/2008/1/21/587456 -- -JH
In message <AANLkTinrhPYXvtS5wtA0PuhtEmi3f4tN9J5KOCBF1a=5@mail.gmail.com>, Mart in Millnert writes:
Jeremy,
I have not heard of any IP stack that is built to accept 240/4. Neither Linux 2.6.37 nor Windows 7 accepts it, and let's not think about all routers, including CPE:s, out there. The logic goes: You are many orders of magnitudes more likely to get v6 off the ground, than 240/4 or 224/4 as unicast IPv4. 224/3 will never be very usable as public v4 space since every non-upgraded host on the Internet will be unable to send packets to them, eg, for every additional host you introduce with these addresses the worse the reachability situation becomes for the v4 Internet. Notably, this is the inverse of what happens when you introduce more hosts with native, proper IPv6, in the IPv6-Internet.
Cheers, Martin
The lines of code to make 240/4 work as unicast << loc to add IPv6 and will usually fit into the amount of flash already on the CPE box. It's a surgical change rather than add a whole new stack. It might even be possible to convice the CPE vendors to make new images for old hardware. You also don't need to make it work with the whole world. Just between the CPE and the LSN and/or 6rd border router. 15 /8's (leave 255 alone) is a lot of space for a ISP to use. The CPE would signal support (e.g. a DHCP option) and the ISP would only return class E addresses if it was sure the path was clean. Those that need a public address would clear the option. It would default on. With luck the asic will support unicast in 240/4 space so you get fast path for IPv6 using 6rd on IPv4 only routers. This model also allows it to be deployed incrementally. This is a software upgrade rather than a hardware upgrade. If you constrain the problem space it becomes more managable problem. The question is do you want to have to deploy the same address space multiple times or is it worth a little bit of co-ordinated effort to do this. IPv4 + IPv6 [NAT/6RD] E space + public IP4 [NAT/6RD] RFC 1918 space + IPv6 It can also be used to deliver IPv6 only over 6rd. IPv4 + IPv6 [AFTR/6RD] E space [B4/6RD] RFC 1918 + IPv6 (double encap) IPv4 + IPv6 [NAT64/6RD] E space [6RD] IPv6 (single encap) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mon, Jan 31, 2011 at 10:31:43PM -0600, Jeremy wrote:
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here)
https://puck.nether.net/pipermail/240-e Last real message? 31 Oct 2007 Done and done. V6, please. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Feb 1, 2011, at 4:31 AM, Jeremy wrote:
Has there been any discussion about allocating the Class E blocks? If this doesn't count as "future use" what does? (Yes, I realize this doesn't *fix* the problem here)
yes. The bottom line is that it only gives you a few more /8s, and every host and router in the net has to be updated to accept them. Doesn't actually solve the problem.
On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 4:55, Jimmy Hess wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
IPv4 is very dead in the sense that it's not going to go anywhere in the future.
The rest is just procrastination.
taking the long view - your statement applies equally to IPv6. of course YMMV --bill
On Feb 1, 2011, at 3:53 AM, bmanning@vacation.karoshi.com wrote:
On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 4:55, Jimmy Hess wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
IPv4 is very dead in the sense that it's not going to go anywhere in the future.
The rest is just procrastination.
taking the long view - your statement applies equally to IPv6.
of course YMMV
--bill
I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years. Owen
On 1 feb 2011, at 13:01, Owen DeLong wrote:
IPv4 is very dead in the sense that it's not going to go anywhere in the future.
taking the long view - your statement applies equally to IPv6.
IPv6 has many places to go in the future. Of course the future is long, and there will be a point when IPv6 is no longer what's needed. But we're nowhere close to that point now.
I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years.
I'm afraid it may be the other way around: lots of IPv4 innovation just so IPv6 can be avoided a few more years.
s/IPv6/ATM/g Just saying... Adrian On Tue, Feb 01, 2011, Iljitsch van Beijnum wrote: > On 1 feb 2011, at 13:01, Owen DeLong wrote: > > >>> IPv4 is very dead in the sense that it's not going to go anywhere in the future. > > >> taking the long view - your statement applies equally to IPv6. > > IPv6 has many places to go in the future. Of course the future is long, and there will be a point when IPv6 is no longer what's needed. But we're nowhere close to that point now. > > > I disagree. I think there is little, if any, innovation that will continue to be put > > into IPv4 hence forth. I think there will be much innovation in IPv6 in the > > coming years. > > I'm afraid it may be the other way around: lots of IPv4 innovation just so IPv6 can be avoided a few more years. -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
On Feb 1, 2011, at 7:01 AM, Owen DeLong wrote:
On Feb 1, 2011, at 3:53 AM, bmanning@vacation.karoshi.com wrote:
On Tue, Feb 01, 2011 at 12:18:17PM +0100, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 4:55, Jimmy Hess wrote:
IPv4's not dead yet; even the first RIR exhaustion probable in 3 - 6 months doesn't end the IPv4 ride.
IPv4 is very dead in the sense that it's not going to go anywhere in the future.
The rest is just procrastination.
taking the long view - your statement applies equally to IPv6.
of course YMMV
--bill
I disagree. I think there is little, if any, innovation that will continue to be put into IPv4 hence forth. I think there will be much innovation in IPv6 in the coming years.
I think that this is what will finally drive true v6 adaptation (as opposed to having it as some sort of super NAT). As v6 innovation continues, v4 will be seen as something obsolete that needs constant work (and v4 innovation will be more and more about patching it to work and keep up with v6). Regards Marshall
Owen
On 2/1/2011 9:13 AM, Marshall Eubanks wrote:
As v6 innovation continues, v4 will be seen as something obsolete that needs constant work (and v4 innovation will be more and more about patching it to work and keep up with v6).
If it continues. The sad thing is, transition would have been a lot smoother if not for IETF politics. "You can't have these features! It's not IPv4! They would work perfectly fine, but we don't want you to do that!" I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. Jack
On 1 feb 2011, at 16:21, Jack Bates wrote:
I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc.
What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? If you like NAT IPv4 is the place to be, it'll only get more and more.
On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 16:21, Jack Bates wrote:
I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses?
Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet. -Dave
----- Original Message -----
On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 16:21, Jack Bates wrote:
I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses?
Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet.
-Dave
So, we should just have no rules or standards at all, and just let people do whatever they want. How well would that work? -Randy
On 2/1/2011 3:10 PM, Randy Carpenter wrote:
----- Original Message -----
On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 16:21, Jack Bates wrote:
I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet.
-Dave So, we should just have no rules or standards at all, and just let people do whatever they want. How well would that work?
We should, and do, have rules and standards for how networks communicate with each other. We can, and should, publish advice on how a network can be built to work properly, internally and externally. We should not say, you must run your internals the way we think a network should be run internally. Every network operator's network is their concern, and making it work is their responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. -Dave
On Tue, 1 Feb 2011, Dave Israel wrote:
responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them.
Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Feb 1, 2011, at 12:36 PM, david raistrick wrote:
On Tue, 1 Feb 2011, Dave Israel wrote:
responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them.
Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback.
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses. It does not solve any other problem(s). As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves rather than working around a problem. Owen
On Tue, 1 Feb 2011, Owen DeLong wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
Sure it does. It obfuscates internal addressing. This wasn't the original goal, but it's a "feature" that some groups of users have come to require. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On 1 feb 2011, at 23:03, david raistrick wrote:
It obfuscates internal addressing.
This wasn't the original goal, but it's a "feature" that some groups of users have come to require.
Creating a new random address every 24 hours (or more often if needed, I assume) goes a long way towards that, too. There's still proxies with IPv6, those also make everything nice and obscure, also hide your TCP seqnums and IP IDs etc.
On 02/01/2011 11:38 AM, Owen DeLong wrote:
On Feb 1, 2011, at 12:36 PM, david raistrick wrote:
On Tue, 1 Feb 2011, Dave Israel wrote:
responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback.
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves rather than working around a problem.
Don't forget the security benefits!!!1111oneone *runs*
On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
In all fairness, that's not really true. It just doesn't solve other problems in an optimal way. Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily have such a requirement. Not that I love NAT66, but let's at least be honest about it. Cheers, -Benson
On Feb 1, 2011, at 2:09 PM, Benson Schliesser wrote:
On Feb 1, 2011, at 3:38 PM, Owen DeLong wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
In all fairness, that's not really true. It just doesn't solve other problems in an optimal way.
Also, NAT44 implies address oversubscription while NAT66 doesn't necessarily have such a requirement.
Not that I love NAT66, but let's at least be honest about it.
Cheers, -Benson
Perhaps a better way to put it is: There are better solutions in IPv6 to any of the problems NAT44 is alleged to solve, regardless of whether you are talking about overloaded NAT44 (which some people refer to as PAT) or any other form of NAT. Owen
On Feb 1, 2011, at 4:38 PM, Owen DeLong <owen@delong.com> wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
That's a bold statement. Especially as you said NAT and not PAT.
On Feb 1, 2011, at 2:56 PM, John Payne wrote:
On Feb 1, 2011, at 4:38 PM, Owen DeLong <owen@delong.com> wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
That's a bold statement. Especially as you said NAT and not PAT.
NAT, PAT, whatever... I'm willing to back it up. Owen
On Feb 1, 2011, at 6:15 PM, Owen DeLong wrote:
On Feb 1, 2011, at 2:56 PM, John Payne wrote:
On Feb 1, 2011, at 4:38 PM, Owen DeLong <owen@delong.com> wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
It does not solve any other problem(s).
That's a bold statement. Especially as you said NAT and not PAT.
NAT, PAT, whatever... I'm willing to back it up.
NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network. In IPv4 this would likely be done with PAT, but I'm looking forward to being able to do something similar with NAT66 (or whatever it ends up being called) without blowing out my internal policies or having to maintain multiple addresses on each end point.
In article <EFC767DA-2CBB-4094-B8D2-553E9EAA2990@sackheads.org>, John Payne <john@sackheads.org> writes
NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network.
And for home (/homeworker) networks ... eg I have a NAT box with a default connection to my ADSL provider and an automatic failover to 3G (completely separate supplier). Almost everything inside my network doesn't notice when it switches over. Now, if only I could get it to automatically revert to ADSL when it reappears - I wouldn't have to worry so much about the 3G bill. -- Roland Perry Nottingham, UK
On Feb 2, 2011, at 1:37 PM, Roland Perry wrote:
In article <EFC767DA-2CBB-4094-B8D2-553E9EAA2990@sackheads.org>, John Payne <john@sackheads.org> writes
NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network.
And for home (/homeworker) networks ... eg I have a NAT box with a default connection to my ADSL provider and an automatic failover to 3G (completely separate supplier).
Almost everything inside my network doesn't notice when it switches over.
Now, if only I could get it to automatically revert to ADSL when it reappears - I wouldn't have to worry so much about the 3G bill.
-- Roland Perry Nottingham, UK
In this case in IPv6, the better choice is to have addresses on each host from both providers. When a provider goes away, the router should invalidate the prefix in the RAs. If the hosts have proper address selection policies, they will actually go back to the ADSL prefix as soon as it reappears. Owen
In article <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com>, Owen DeLong <owen@delong.com> writes
NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network.
And for home (/homeworker) networks ... eg I have a NAT box with a default connection to my ADSL provider and an automatic failover to 3G (completely separate supplier).
Almost everything inside my network doesn't notice when it switches over.
Now, if only I could get it to automatically revert to ADSL when it reappears - I wouldn't have to worry so much about the 3G bill.
In this case in IPv6, the better choice is to have addresses on each host from both providers. When a provider goes away, the router should invalidate the prefix in the RAs. If the hosts have proper address selection policies, they will actually go back to the ADSL prefix as soon as it reappears.
Which in turn implies that I'd have to start getting involved in DNS for the hosts inside my network. At the moment I can ignore that and just enter their rfc1918 address into various applications. [This is all under Windows, of course, the sort of user I'm playing at being doesn't use anything more sophisticated.] In any event, two of my applications are not IPv6 compatible, and would require significant upgrading. And will my ADSL provider and my 3G provider both switch to IPv6 at about the same time? Unfortunately this all sounds like a lot of work, but am I a rare kind of user? -- Roland Perry
In message <WONcR2eTFwSNFAMT@perry.co.uk>, Roland Perry writes:
In article <5A055785-D55E-47A3-87B0-58B0DE81F60E@delong.com>, Owen DeLong <owen@delong.com> writes
NAT provides a solution to, lets call it, enterprise multihoming. Remote office with a local Internet connection, but failover through the corporate network.
And for home (/homeworker) networks ... eg I have a NAT box with a default connection to my ADSL provider and an automatic failover to 3G (completely separate supplier).
Almost everything inside my network doesn't notice when it switches over.
Now, if only I could get it to automatically revert to ADSL when it reappears - I wouldn't have to worry so much about the 3G bill.
In this case in IPv6, the better choice is to have addresses on each host from both providers. When a provider goes away, the router should invalidate the prefix in the RAs. If the hosts have proper address selection policies, they will actually go back to the ADSL prefix as soon as it reappears.
Which in turn implies that I'd have to start getting involved in DNS for the hosts inside my network. At the moment I can ignore that and just enter their rfc1918 address into various applications.
No, you can enter their ULA if you don't want to use the DNS. For external client you enter both their external addresses in the DNS. Clients don't need to be stupid about connecting to a multi-homed server. It's just that the client developers have ignored RFC 1123's suggestions for 20+ years and there hasn't been a lot of multi-homed servers. See the following for C code that works well even when the network layer fails to report connection errors to the application. http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-ser... If a application you depend apon doesn't do something like this complain to its developers. UDP is harder but not impossible. DNS is a classic example. DNS servers deal with UDP over dead network paths and has done for the last 20 years.
[This is all under Windows, of course, the sort of user I'm playing at being doesn't use anything more sophisticated.]
In any event, two of my applications are not IPv6 compatible, and would require significant upgrading. And will my ADSL provider and my 3G provider both switch to IPv6 at about the same time?
You shouldn't have to care. Properly written clients will connect over whatever is available without significant delay and since you are multi-homed you really do want your clients to be properly written. If they are not complain to your vendor as they are not meeting the RFC 1123 requirements.
Unfortunately this all sounds like a lot of work, but am I a rare kind of user? -- Roland Perry -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In article <20110203220604.A8BAE9A5102@drugs.dv.isc.org>, Mark Andrews <marka@isc.org> writes
In any event, two of my applications are not IPv6 compatible, and would require significant upgrading. And will my ADSL provider and my 3G provider both switch to IPv6 at about the same time?
You shouldn't have to care. Properly written clients will connect over whatever is available without significant delay and since you are multi-homed
I'd call it more alternate-homed.
you really do want your clients to be properly written. If they are not complain to your vendor as they are not meeting the RFC 1123 requirements.
One client is no longer maintained (but I am very attached to it). The other is nailed inside a five-year-old VoIP box and I suspect they'll say "buy a new one". These are just my straw poll of what may be difficult for small enterprises in a change to IPv6. -- Roland Perry
In message <WHKMjz3PUzSNFAcx@perry.co.uk>, Roland Perry writes:
In article <20110203220604.A8BAE9A5102@drugs.dv.isc.org>, Mark Andrews <marka@isc.org> writes
In any event, two of my applications are not IPv6 compatible, and would require significant upgrading. And will my ADSL provider and my 3G provider both switch to IPv6 at about the same time?
You shouldn't have to care. Properly written clients will connect over whatever is available without significant delay and since you are multi-homed
I'd call it more alternate-homed.
you really do want your clients to be properly written. If they are not complain to your vendor as they are not meeting the RFC 1123 requirements.
One client is no longer maintained (but I am very attached to it). The other is nailed inside a five-year-old VoIP box and I suspect they'll say "buy a new one".
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. Mark
-- Roland Perry
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In article <20110204000954.A64C79A9FED@drugs.dv.isc.org>, Mark Andrews <marka@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
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 AAAA 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
In article <5FDDAD27-71F3-44FE-B195-4E0F27F09EC5@megacity.org>, Derek J. Balling <dredd@megacity.org> writes
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 AAAA record it gets from a DNS lookup?
The IPv4 only hosts (and gradually they'll be converted to dual stack and IPv6 capable, some are there already) will only be able to see IPv4 resources on the wider Internet. I'd have to decide on a case by case basis (one case being a particular VoIP service I subscribe to) when those hosts of mine needed early replacement on account of the provider switching off his end. (My point here mainly being that it's not just a case of simply reconfiguring them, if they simply don't have any IPv6 capability). For those familiar with Windows, it's not dissimilar to my recent decision to update one of my desktops to XP, because so much software (mainly device drivers) no longer supports Win2000. But then you find you have apps that won't run under XP <sigh> [more likely on a jump from XP to Vista, but you get my point].
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....
I don't know if it's the "wonky behaviour" you describe, but I'd have expected any IPv6 traffic inside the network to go round the side of the NAT functionality (ie behave as if the IPv4 NAT wasn't there). But we've drifted a bit away from the earlier problem of how I can make all the hosts on my internal network "hop" between ISPs with in effect no user intervention (and no pre-emptive configuration). I'll let this pass for now and see how the market/technology develops. -- Roland Perry
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 AAAA record it gets from a DNS lookup?
If the CPE is doing DNS proxy (most do) then it can map the AAAA 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 AAAA 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.
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 AAAA record it gets from a DNS lookup?
If the CPE is doing DNS proxy (most do) then it can map the AAAA 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 AAAA 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
In message <201102041140.42719.lowen@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 AAAA record it gets from a DNS lookup?
If the CPE is doing DNS proxy (most do) then it can map the AAAA 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 AAAA 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Feb 4, 2011, at 4:32 PM, Mark Andrews wrote:
In message <201102041140.42719.lowen@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 AAAA record it gets from a DNS lookup?
If the CPE is doing DNS proxy (most do) then it can map the AAAA 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 AAAA 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
In message <FE7943DF-6A3A-478F-AF40-DE4D3592FB1D@puck.nether.net>, Jared Mauch writes:
On Feb 4, 2011, at 4:32 PM, Mark Andrews 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 inter nal host know what to do with an IPv6 AAAA record it gets from a DNS = lookup? =20 If the CPE is doing DNS proxy (most do) then it can map the AAAA = 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 =
gned RFC1918 address to the external IPv6 address from the AAAA = 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 =
=20 In message <201102041140.42719.lowen@pari.edu>, Lamar Owen writes: the assi 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: marka@isc.org
In message <WQE8G0a2F$SNFA9t@perry.co.uk>, Roland Perry writes:
In article <20110204000954.A64C79A9FED@drugs.dv.isc.org>, Mark Andrews <marka@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: marka@isc.org
In message <EFC767DA-2CBB-4094-B8D2-553E9EAA2990@sackheads.org>, John Payne wri tes:
On Feb 1, 2011, at 6:15 PM, Owen DeLong wrote:
=20 On Feb 1, 2011, at 2:56 PM, John Payne wrote: =20
=20 =20 On Feb 1, 2011, at 4:38 PM, Owen DeLong <owen@delong.com> wrote: =20
NAT solves exactly one problem. It provides a way to reduce address = consumption to work around a shortage of addresses. =20 It does not solve any other problem(s). =20 =20 That's a bold statement. Especially as you said NAT and not PAT.
NAT, PAT, whatever... I'm willing to back it up.
NAT provides a solution to, lets call it, enterprise multihoming. = Remote office with a local Internet connection, but failover through the = corporate network. In IPv4 this would likely be done with PAT, but I'm looking forward to = being able to do something similar with NAT66 (or whatever it ends up = being called) without blowing out my internal policies or having to = maintain multiple addresses on each end point.=
Or you could give them all two addresses and set the address selection policy so that when the local connection is up those addresses are used and when it is down the other addresses are used to source traffic. The router just send a RA with a prefix lifetime of zero when it looses upstream connectivity for that prefix putting all addresses on that prefix into deprecated state. Yes this is different to IPv4 and it doesn't require NAT66 to work. Just something to think about. IPv6 is different to IPv4. It has different capabilities. It offers different solutions to old problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2/1/2011 3:38 PM, Owen DeLong wrote:
As such, taking it away when giving you a large enough address space that there is no longer a shortage doesn't strike me as taking away a tool that solves a problem. It strikes me as giving you a vastly superior tool that solves rather than working around a problem.
Interestingly enough, there is a draft for NAT66, specifically NPTv6, but no draft for NAPTv6. So someone though it was okay to start allowing some NAT66, but everyone's still trying to fight NAPTv6, as businesses might use it. Oh noes. The other concern was perhaps home routers, but let's be honest. There is a v6-cpe-router draft, and it easily could forbid the use of NAPTv6. It's already missing most of the stuff required to make home networks work in v6 the same way they do in v4 (prefix delegation added new problems that NAT didn't have, which they still haven't solved). Jack
On Tue, 2011-02-01 at 13:38 -0800, Owen DeLong wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. The side effects of that are not necessarily desirable (loss of end-to-end connectivity, performance issues, limitations on simultaneous connections etc etc). It seems to me that it is this property of NAT that people are most loath to lose. And why ULA looks tantalisingly delicious. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
On Feb 1, 2011, at 3:41 PM, Karl Auer wrote:
On Tue, 2011-02-01 at 13:38 -0800, Owen DeLong wrote:
NAT solves exactly one problem. It provides a way to reduce address consumption to work around a shortage of addresses.
Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing.
Which is a bug, not a feature.
The side effects of that are not necessarily desirable (loss of end-to-end connectivity, performance issues, limitations on simultaneous connections etc etc).
Exactly.
It seems to me that it is this property of NAT that people are most loath to lose. And why ULA looks tantalisingly delicious.
Yeah, but, if we take a step back and look for what they actually want that they are willing to give up everything else to get, it usually boils down to two things: 1. Obfuscation of host addresses 2. Ability to move an entire topology from one number space to another without reconfiguring the topology. IPv6 solves 1 with privacy addresses. These are horrible and I hope nobody really uses them, but, they're better than NAT. 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. Owen
Once upon a time, Owen DeLong <owen@delong.com> said:
On Feb 1, 2011, at 3:41 PM, Karl Auer wrote:
Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing.
Which is a bug, not a feature.
That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people "I'm right, you're wrong" over and over again leads to them going away and ignoring IPv6. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Feb 1, 2011, at 6:24 PM, Chris Adams wrote:
Once upon a time, Owen DeLong <owen@delong.com> said:
On Feb 1, 2011, at 3:41 PM, Karl Auer wrote:
Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing.
Which is a bug, not a feature.
That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people "I'm right, you're wrong" over and over again leads to them going away and ignoring IPv6.
Using this definition of bug from Wikipedia: A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above. Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to consider said bug to be a feature, but, it is, by definition, factually, a bug. Owen
On 2/1/2011 9:33 PM, Owen DeLong wrote:
On Feb 1, 2011, at 6:24 PM, Chris Adams wrote:
On Feb 1, 2011, at 3:41 PM, Karl Auer wrote:
Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing.
Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people "I'm right, you're wrong" over and over again leads to
Once upon a time, Owen DeLong<owen@delong.com> said: them going away and ignoring IPv6.
Using this definition of bug from Wikipedia:
A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.
I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above.
Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to consider said bug to be a feature, but, it is, by definition, factually, a bug.
I apologize in advance for the strong wording, and will apologize for it in person (with a beer) at some point. But: A NATed client connects to a server, and they speak end to end. A NATed server receives connections directly from clients. It is more or less end to end, communications-wise, and so it is the same or less of a "bug," by your definition, than a proxy server, or a web cache, or ipv4 anycast DNS, or inspecting/fixup capable firewalls. And those are all things people want. If you are advocating that IPv6 should not be capable of performing tasks people want it to perform, then you are advocating for IPv6 to follow the path of the OSI protocols as a "could have been the new Internet" protocol, and you are pushing the world toward the NATernet, and you are actually, unintentionally, one of IPv6's worst enemies. Look back across all the big arguments over the years that had people turning purple and calling each other names and declaring that IPv6 was broken. They are all about features in IPv6 that operators did not want, because directly or indirectly, they either disabled features people use now, or they told people how hey had to build their networks. They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. You can blame sloth, ignorance, and heads in the sand all you want for the long wait for IPv6 adoption, but the insistence by IPv6 evangelists that IPv4-think is necessarily evil and that they are going to force everybody to conform to their perfect paradigm is also a big factor. And this isn't just a perception issue, or rebellion at being told what to do. Part of what made IPv4 so successful was that its simplicity made it inherently flexible, and even operators who are wrong about what things like NAT give them are right to rebel against restricting flexibility to meet certain people's perception of what network purity means today. -Dave
On 2/1/2011 9:51 PM, Dave Israel wrote:
They were features dreamed up by academics, theoreticians, and purists, and opposed by operators.
You mean like the lack of Default Router in DHCPv6? Don't get me wrong. I love RA. However, it is NOT a universal tool, and there are cases where Default Router via DHCPv6 would be more appropriate and easier to manage. Case in point. If I hand out IA_NA or IA_TA to directly connected DSL hosts or CPEs, I have no need of RA. In addition, the load on my router is increased by having to send RA to 3000+ interfaces, something that is absolutely not necessary in my deployment. I would even go as far to say that Default Router would be a good stateless option to hand out along with the DNS servers when customers do SLAAC with me. 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
On Feb 1, 2011, at 9:02 PM, Jack Bates wrote:
On 2/1/2011 9:51 PM, Dave Israel wrote:
They were features dreamed up by academics, theoreticians, and purists, and opposed by operators.
You mean like the lack of Default Router in DHCPv6?
The whole SLAAC vs. DHCPv6 argument is a complete debacle. What IETF should have done there is provide two complete protocols that operators could make the choice or combination of choices that worked best for them. Instead, the two camps spent so much time and energy disrupting the other protocol that instead, we have two completely incomplete protocols and you need to use a weird combination of the two just to get basic functionality. There is ongoing work to complete them both now that operators have noticed, but, it is unfortunate this was so badly delayed.
Don't get me wrong. I love RA. However, it is NOT a universal tool, and there are cases where Default Router via DHCPv6 would be more appropriate and easier to manage.
Yep. This is an example of a missing feature. I'm in complete agreement. NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT. Owen
On Feb 2, 2011, at 11:40 AM, John Payne wrote:
On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote:
NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT.
Examples?
SIP Network enabled Video Games Peer to Peer services of various forms etc. Owen
On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote:
On Feb 2, 2011, at 11:40 AM, John Payne wrote:
On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote:
NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT.
Examples?
SIP Network enabled Video Games Peer to Peer services of various forms etc.
I chose NAT66. How does that affect you or any other site? Note that I have already blocked games and peer to peer either technically or via policy.... and I have no SIP end points that have any business talking outside the enterprise. Just rephrasing you slightly. NAT66 will break applications that many enterprises will already have blocked at their perimeters.
I must have missed something. Why would u do NAT in IPv6? John Payne <john@sackheads.org> wrote: On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote:
On Feb 2, 2011, at 11:40 AM, John Payne wrote:
On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote:
NAT66 is different. NAT66 breaks things in ways that impact sites outside of the site choosing to deploy NAT.
Examples?
SIP Network enabled Video Games Peer to Peer services of various forms etc.
I chose NAT66. How does that affect you or any other site? Note that I have already blocked games and peer to peer either technically or via policy.... and I have no SIP end points that have any business talking outside the enterprise. Just rephrasing you slightly. NAT66 will break applications that many enterprises will already have blocked at their perimeters.
On 2/2/2011 5:42 PM, Brian Johnson wrote:
I must have missed something. Why would u do NAT in IPv6?
1) To allow yourself to change or maintain multiple upstreams without renumbering. 2) To allow your IPv6-only hosts to reach IPv4 addresses, or vice versa. 3) To give all your outbound sessions a mutual appearance, so as to confound those attempting to build a profile of your activity. 4) To irritate the IPv6 faithful. 5) Because it is funny. 6) Because you have allocated a single address to a machine that later on actually represents n differerent actual network entities, and retrofitting them with their own unique IPv6 subnet presents a problem. 7) Because Iljitch bet you you couldn't, and you don't want to lose a bet. 8) Because chicks/dudes think it's hot. 9) Because you can. 10) Because it is the year 8585, and we're running low on IPv6 addresses.
I will rebut in-line.
-----Original Message----- From: Dave Israel [mailto:davei@otd.com] Sent: Wednesday, February 02, 2011 11:57 PM To: nanog@nanog.org Subject: Re: quietly....
On 2/2/2011 5:42 PM, Brian Johnson wrote:
I must have missed something. Why would u do NAT in IPv6?
1) To allow yourself to change or maintain multiple upstreams without renumbering.
Not sure what you mean here. So having PI space can't accomplish this?
2) To allow your IPv6-only hosts to reach IPv4 addresses, or vice versa.
This is not a NAT66 specific solution.
3) To give all your outbound sessions a mutual appearance, so as to confound those attempting to build a profile of your activity.
So this goes back to security through obscurity. OK.
4) To irritate the IPv6 faithful. 5) Because it is funny.
Oh yeah, I forgot that you were funny. :)
6) Because you have allocated a single address to a machine that later on actually represents n differerent actual network entities, and retrofitting them with their own unique IPv6 subnet presents a problem.
Huh?
7) Because Iljitch bet you you couldn't, and you don't want to lose a bet. 8) Because chicks/dudes think it's hot. 9) Because you can. 10) Because it is the year 8585, and we're running low on IPv6 addresses
OK... so this list of ten boils down to really two items that seem completely valid and one that seems like a corner case, but are also not the purpose of NAT66 as far as I can tell. Anyone else without the sarcasm? - Brian P.S... I'm not against NAT66, I just don't yet understand it at the layers above 7. :)
On Thu, 3 Feb 2011, Brian Johnson wrote:
3) To give all your outbound sessions a mutual appearance, so as to confound those attempting to build a profile of your activity.
So this goes back to security through obscurity. OK.
There's an awful lot of inertia in the "NAPT/firewall keeps our hosts safe from the internet" mentality. Sure, a stateful firewall can be configured allow all outbound traffic and only connected/related inbound. When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want. People are going to want NAT66...and not providing it may slow down IPv6 adoption. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
----- Original Message -----
From: "Jon Lewis" <jlewis@lewis.org>
There's an awful lot of inertia in the "NAPT/firewall keeps our hosts safe from the internet" mentality. Sure, a stateful firewall can be configured allow all outbound traffic and only connected/related inbound.
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
Precisely. This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
You're using the future tense there, Jon; are you sure you didn't mean to use the present? Or the past...? Cheers, -- jra
There is also another reason for NAT44 or NAT66 in the corporate world that has been missed in these conversations. It is very common to NAT44 when connected via extranets to another company via an b2b provider such as TNS or BTRadianz. Not everything goes over the net. NAT44 (especially "twice-nat") is used for a number of reasons including limiting of exchange of routing information, routing of different services in different directions via NAT, or to prevent having to contact the other side when a server changes. For example if we are natting one of our FIX servers then the internal machine can change as long as the NAT is updated. This is far simpler than having to get the changes externally especially at some big bank. Also some companies bring internet routes into their core (I still don't know why). In order to route web/email to them via the internet and protocols such as FIX via an extranet, twice-nat is required. Within similar function in Ipv6, there are a lot of companies, especially in the financial realm, that won't migrate off of ipv4. NAT is used for a reason, not just because "we don't know better". Yes, we know it breaks certain apps, especially p2p ones. In a corporate view, that is a feature, not a bug. We neither want, nor will allow individual desktops to become peers. Only a limited number of dedicated servers have external visibility, and that's the way it's going to stay regardless of ipv6 ideology.
-----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Thursday, February 03, 2011 11:29 AM To: NANOG Subject: Re: quietly....
----- Original Message -----
From: "Jon Lewis" <jlewis@lewis.org>
There's an awful lot of inertia in the "NAPT/firewall keeps our hosts safe from the internet" mentality. Sure, a stateful firewall can be configured allow all outbound traffic and only connected/related inbound.
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
Precisely.
This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
You're using the future tense there, Jon; are you sure you didn't mean to use the present? Or the past...?
Cheers, -- jra
On Feb 3, 2011, at 8:46 AM, Matthew Huff wrote:
There is also another reason for NAT44 or NAT66 in the corporate world that has been missed in these conversations. It is very common to NAT44 when connected via extranets to another company via an b2b provider such as TNS or BTRadianz. Not everything goes over the net. NAT44 (especially "twice-nat") is used for a number of reasons including limiting of exchange of routing information, routing of different services in different directions via NAT, or to prevent having to contact the other side when a server changes. For example if we are natting one of our FIX servers then the internal machine can change as long as the NAT is updated. This is far simpler than having to get the changes externally especially at some big bank. Also some companies bring internet routes into their core (I still don't know why). In order to route web/email to them via the internet and protocols such as FIX via an extranet, twice-nat is required.
Within similar function in Ipv6, there are a lot of companies, especially in the financial realm, that won't migrate off of ipv4.
In IPv6, the simpler solution is to allocate a /64 to groups of machines that serve such a function. If you need to move the group, you can simply move the entire prefix.
NAT is used for a reason, not just because "we don't know better". Yes, we know it breaks certain apps, especially p2p ones. In a corporate view, that is a feature, not a bug. We neither want, nor will allow individual desktops to become peers. Only a limited number of dedicated servers have external visibility, and that's the way it's going to stay regardless of ipv6 ideology.
Actually, there are better alternatives to NAT in IPv6 for just about every reason, so, yeah, the desire for NAT in IPv6 really does boil down to "we don't know better yet". You can break p2p just as quickly without NAT using policy. NAT doesn't provide policy, it just limits your ability to choose your own policy. Owen
-----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Thursday, February 03, 2011 11:29 AM To: NANOG Subject: Re: quietly....
----- Original Message -----
From: "Jon Lewis" <jlewis@lewis.org>
There's an awful lot of inertia in the "NAPT/firewall keeps our hosts safe from the internet" mentality. Sure, a stateful firewall can be configured allow all outbound traffic and only connected/related inbound.
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
Precisely.
This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
You're using the future tense there, Jon; are you sure you didn't mean to use the present? Or the past...?
Cheers, -- jra
In IPv6, the simpler solution is to allocate a /64 to groups of machines that serve such a function. If you need to move the group, you can simply move the entire prefix.
If we change the prefix, then I have to contact and deal with the bureaucracy of external corporate entities. This is a significant cost that is completely prevented by using NAT. Also, given that the prefix is a network address, now we have to contact a separate department with a separate bureaucracy to get routing changes approved. Again, how is this easier without nat?
You can break p2p just as quickly without NAT using policy. NAT doesn't provide policy, it just limits your ability to choose your own policy.
The goal is not to break p2p. The goal is to use NAT for various reasons, and the fact that it breaks p2p is just a benefit. You keep pointing out that NAT should be eliminated so that p2p will work, to me, that is an good argument for the opposite. NAT, at least in a coroprate world, is never going away. There are two many good reasons for it to exist. For a ISP/CPE or University environment, I understand your argument, but not for a corporate network. If there were a good NAT46 implementation on a cisco asa, juniper firewall, checkpoint and others, then most corporate networks could stay in ipv4 RFC1918 private IP addresses, get PA ipv6 global routable address space from their providers, and setup global NAT pools and have access to ipv4 and ipv6 with no internal changes. It may not be ideologically pure, but it would work, as least as well as it does now, and allow the migration to ipv6 to move forward easier.
On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Jon Lewis" <jlewis@lewis.org>
There's an awful lot of inertia in the "NAPT/firewall keeps our hosts safe from the internet" mentality. Sure, a stateful firewall can be configured allow all outbound traffic and only connected/related inbound.
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
Precisely.
This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.
So does any decent stateful inspection firewall. That's why your argument doesn't hold water. The only thing NAT brings to the equation over a properly constructed stateful firewall is the mutilation of the IP header.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
You're using the future tense there, Jon; are you sure you didn't mean to use the present? Or the past...?
If the lack of NAT66 slows down IPv6 adoption, even though I am a big IPv6 cheerleader, I am willing to accept that particular tradeoff. Overloaded NAT is too costly to the community to be allowed to promulgate into IPv6. It is detrimental to: Application development Innovation Security Auditing Cost: Cost of application development Cost of devices Cost of administration Cost of operations People that hold steadfast to the idea of not implementing IPv6 without NAT will eventually become IPv4 islands. The rest of the internet will continue to innovate without them and they will eventually come along or they will be left behind. Owen
On 2/3/2011 12:17 PM, Owen DeLong wrote:
Cost of application development
Applications do not have to be written to support NAT (NAT66 shouldn't find itself in the areas where it's traditionally been a problem). The burden should be upon the NAT device to fix any issues, and this will be paid for by the few that utilize NAT.
Cost of devices
Cost of border firewalls you mean; also not an issue.
Cost of administration
If I choose to use NAPTv6, it's right to accept this cost. It doesn't make someone else pay more for me to administer my firewall.
Cost of operations
If I choose to use NAPTv6, it's right to accept this cost. It doesn't make someone else pay more for me to administer my firewall. I understand and agree that CPEs should not use NAT66. It should even be a MUST NOT in the cpe router draft. However, there is no cost benefit of denying it to corporate border firewalls, and it most likely will be implemented anyways, so it should be properly documented. Jack
On Thursday, February 03, 2011 01:35:46 pm Jack Bates wrote:
I understand and agree that CPEs should not use NAT66. It should even be a MUST NOT in the cpe router draft.
Do you really think that this will stop the software developers of some CPE routers' OS code from just making it work? Do you really think the standard saying 'thou shalt not NAT' will produce the desired effect of preventing such devices from actually getting built?
On 2/3/2011 1:04 PM, Lamar Owen wrote:
On Thursday, February 03, 2011 01:35:46 pm Jack Bates wrote:
I understand and agree that CPEs should not use NAT66. It should even be a MUST NOT in the cpe router draft.
Do you really think that this will stop the software developers of some CPE routers' OS code from just making it work? Do you really think the standard saying 'thou shalt not NAT' will produce the desired effect of preventing such devices from actually getting built?
Do you think we have to have a standard for them to implement it? If they can ignore the CPE router rules, they can implement NAT66 on their own, too. Jack
On 2011-02-03 15:29, Lamar Owen wrote:
On Thursday, February 03, 2011 02:55:39 pm Jack Bates wrote:
Do you think we have to have a standard for them to implement it?
If they can ignore the CPE router rules, they can implement NAT66 on their own, too.
See the map66 Sourceforge.net project. Already happening.
OpenBSD's pf has had stateful NAT66 for many years... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca
On Thu, Feb 03, 2011 at 12:35:46PM -0600, Jack Bates wrote:
On 2/3/2011 12:17 PM, Owen DeLong wrote:
Cost of application development
Applications do not have to be written to support NAT (NAT66 shouldn't find itself in the areas where it's traditionally been a problem). The burden should be upon the NAT device to fix any issues, and this will be paid for by the few that utilize NAT.
You're joking, right?
Cost of administration
If I choose to use NAPTv6, it's right to accept this cost. It doesn't make someone else pay more for me to administer my firewall.
Cost of operations
If I choose to use NAPTv6, it's right to accept this cost. It doesn't make someone else pay more for me to administer my firewall.
Oh wait... you're *serious*? Have you never in your career come up against another party that says "this is how we do it, and if you want to do business with us you can do it our way or get stuffed"? All of a sudden, their decision to use NAT and/or do other spectacularly stupid things with their networks impacts on *me*[1], and costs *me* money. It doesn't work out like the optimistic utopia you're espousing. - Matt [1] Is there such thing as a "royal me"? There should be.
Overloaded NAT is too costly to the community to be allowed to promulgate into IPv6. It is detrimental to: Application development Innovation Security Auditing Cost: Cost of application development Cost of devices Cost of administration Cost of operations
People that hold steadfast to the idea of not implementing IPv6 without NAT will eventually become IPv4 islands. The rest of the internet will continue to innovate without them and they will eventually come along or they will be left behind.
Owen
Owen, can you point to a application protocol that is broken via NAT that isn't a p2p protocol or VoIP? Corporations are interested in neither (except SIP trunking, which works fine with NAT). Corporate networks have zero interest in p2p protocols or allowing desktops to be "full members" of the ip world. Like I posted earlier, there are signficant reasons to use NAT44 and NAT66 that have nothing to do with perceived security, but rather with virtualization of ip endpoints/ip routing used by companies such as TNS and BTRadianz for extranet connectivity. From our standpoint NAT44 is a signifcant cost reduction because it allows us to make changes to internal environments without having to coordinate with all of our extranet partners. The difference is significant. In a very simple example, changing one of our FIX servers with the extranet clients being twice-natted, requires one change on one firewall. If I had to contact all the clients (and no, they can't use dynamic routing and/or DNS), then it would require hours of paperwork and time coordinating it. It's not even close.
On Thu, 03 Feb 2011 13:41:26 EST, Matthew Huff said:
Owen, can you point to a application protocol that is broken via NAT that isn't a p2p protocol or VoIP?
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. I'm told that IPSEC through a NAT can be interesting too... And that's something I'm also told some corporations are interested in.
Trust me, I'm very familiar with FTP and firewalls. The problem is not just with NAT, but exists with SPI. Both are solved problems that work with NAT. Something like ftp over SSH works well without fixup or NAT issues and is becoming more standard at least in the financial services community. IPSEC to a NAT/SPI firewall works fine, through it has issues. But then again, rarely do you want that in a corporate network anyway.
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Thursday, February 03, 2011 2:29 PM To: Matthew Huff Cc: Owen DeLong; nanog@nanog.org Subject: Re: quietly....
On Thu, 03 Feb 2011 13:41:26 EST, Matthew Huff said:
Owen, can you point to a application protocol that is broken via NAT that isn't a p2p protocol or VoIP?
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.
I'm told that IPSEC through a NAT can be interesting too... And that's something I'm also told some corporations are interested in.
Well, since ssh is a straight up tcp socket protocol on a well know port with no gimmicks needed like FTP, yeah, I would say it isn't a hack. FTP over TLS/SSL is much worse. In some implementations you can do an non-encrypted control channel and an encrypted data channel, so that a SPI firewall can "hack" it through, but unfortunately a lot of servers and/or clients won't negotiate that correctly and only allow both type of channels to be encrypted which is not possible to pass through a SPI firewall. There are two other sorta widely implemented secure file transfer protocols, SCP and WebDav over TLS/SSL. Either works fine through a SPI firewall, but the consensus for file transfer (at least over the pub net) within the financial services community appears to be converging to FTP over ssh.
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Thursday, February 03, 2011 3:36 PM To: Matthew Huff Cc: Owen DeLong; nanog@nanog.org Subject: Re: quietly....
On Thu, 03 Feb 2011 14:39:15 EST, Matthew Huff said:
Something like ftp over SSH works well without fixup or NAT issues and is becoming more standard at least in the financial services community.
And having to do it over SSH *isn't* a fixup/hackaround?
----- Original Message -----
Well, since ssh is a straight up tcp socket protocol on a well know port with no gimmicks needed like FTP, yeah, I would say it isn't a hack. FTP over TLS/SSL is much worse. In some implementations you can do an non-encrypted control channel and an encrypted data channel, so that a SPI firewall can "hack" it through, but unfortunately a lot of servers and/or clients won't negotiate that correctly and only allow both type of channels to be encrypted which is not possible to pass through a SPI firewall.
There are two other sorta widely implemented secure file transfer protocols, SCP and WebDav over TLS/SSL. Either works fine through a SPI firewall, but the consensus for file transfer (at least over the pub net) within the financial services community appears to be converging to FTP over ssh.
Do you mean sftp, or ftp over an ssh tunnel? -Randy
Oh, don't get me started on the confusion between FTP over SSH versus FTP over TLS/SSL let alone ftp over ssh versus sftp. So many vendors and users use ftps or sftp indiscriminately to describe both and neither. By sftp, I mean ftp over ssh (not tunnelled) as an alternate to scp. I would personally prefer scp to sftp, but that isn't what is being deployed by our peers.
-----Original Message----- From: Randy Carpenter [mailto:rcarpen@network1.net] Sent: Thursday, February 03, 2011 4:32 PM To: Matthew Huff Cc: nanog@nanog.org; Valdis Kletnieks Subject: Re: quietly....
----- Original Message -----
Well, since ssh is a straight up tcp socket protocol on a well know port with no gimmicks needed like FTP, yeah, I would say it isn't a hack. FTP over TLS/SSL is much worse. In some implementations you can do an non-encrypted control channel and an encrypted data channel, so that a SPI firewall can "hack" it through, but unfortunately a lot of servers and/or clients won't negotiate that correctly and only allow both type of channels to be encrypted which is not possible to pass through a SPI firewall.
There are two other sorta widely implemented secure file transfer protocols, SCP and WebDav over TLS/SSL. Either works fine through a SPI firewall, but the consensus for file transfer (at least over the pub net) within the financial services community appears to be converging to FTP over ssh.
Do you mean sftp, or ftp over an ssh tunnel?
-Randy
On Thursday, February 03, 2011 02:28:32 pm Valdis.Kletnieks@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.
I'm told that IPSEC through a NAT can be interesting too... And that's something I'm also told some corporations are interested in.
IPsec NAT Traversal over UDP port 4500 works ok, but it does require port-forwarding (either manual, automatic-in-the-router, or uPNP) to work ok. There are a number of HOWTO's out there to make it work, and we've been doing it between the native Windows L2TP VPN client (PPTP is insecure; L2TP as implemented by Microsoft is a three layer melange of PPP on top, with L2TP carrying that, encapsulated in IPsec between two endpoints) and SmoothWall's SmoothTunnel for several years. It does work, and it's not as hard as it could be. But it's not as easy as it should be, at least on the network plumbing side of things. However, that's not typically the hardest part of setting up a Microsoft-style PPPoL2TPoIPsec VPN, though, especially if you use certificates instead of preshared keys.
On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote:
On Thursday, February 03, 2011 02:28:32 pm Valdis.Kletnieks@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
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:mpalmer@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.Kletnieks@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
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Thu, 03 Feb 2011 16:41:12 EST, Matthew Huff said:
SMTP is definitely not a p2p protocol in most corporate environments.
Ahem. Please quit confusing "the protocol" with "that small segment of the protocol we choose to allow/support on our network".
Ahem. Please quit confusing "The Internet" with "my small edge network, which I interconnect with The Internet". Cheers, -- jra
On Thu, 03 Feb 2011 17:01:52 EST, Jay Ashworth said:
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Thu, 03 Feb 2011 16:41:12 EST, Matthew Huff said:
SMTP is definitely not a p2p protocol in most corporate environments.
Ahem. Please quit confusing "the protocol" with "that small segment of the protocol we choose to allow/support on our network".
Ahem.
Please quit confusing "The Internet" with "my small edge network, which I interconnect with The Internet".
Corporations use a different version of RFC5321 that's 30% shorter and removes features they happen to not use? Or are they using the same RFC5321, but simply not using all the features? The distinction is in fact important.
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Thu, 03 Feb 2011 17:01:52 EST, Jay Ashworth said:
Ahem. Please quit confusing "the protocol" with "that small segment of the protocol we choose to allow/support on our network".
Ahem.
Please quit confusing "The Internet" with "my small edge network, which I interconnect with The Internet".
Corporations use a different version of RFC5321 that's 30% shorter and removes features they happen to not use? Or are they using the same RFC5321, but simply not using all the features?
Probably the latter. C'mon; this isn't *your* first rodeo, either. From the viewpoint of The Internet, *my edge router* is The Node -- as long as everything gets to there ok, it's nunya damn business what I do inside. Only what comes out. That's Why I Have A Router. Cheers, -- jra
On Thursday, February 03, 2011 05:30:15 pm Jay Ashworth wrote:
C'mon; this isn't *your* first rodeo, either. From the viewpoint of The Internet, *my edge router* is The Node
Isn't that where this thing all started, with ARPAnet 'routers' on those leased lines? End-to-end is in reality, these days, AS-to-AS. Beyond that, each AS can do whatever it wants with those packets; if it wants to insert the full text of the Niagara Falls skit (with copyright owner's permission) into every packet, it can do that, and no other AS can make it do differently. Sure, it would be nice in ways to have full end to end at the individual host level, everybody has static addresses and domain names are free and address space at the /64 level is portable to kingdom come and back without routing table bloat.... NAT in IPv4 came about because people were doing it, and the standards were after the fact. Deja Vu, all over again. Make it easy to do what people want to do, but without NAT, perhaps overloading, port-translating NAT66 won't get traction.
In message <18979697.4665.1296772215500.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Thu, 03 Feb 2011 17:01:52 EST, Jay Ashworth said:
Ahem. Please quit confusing "the protocol" with "that small segment of the protocol we choose to allow/support on our network".
Ahem.
Please quit confusing "The Internet" with "my small edge network, which I interconnect with The Internet".
Corporations use a different version of RFC5321 that's 30% shorter and removes features they happen to not use? Or are they using the same RFC5321, but simply not using all the features?
Probably the latter.
C'mon; this isn't *your* first rodeo, either. From the viewpoint of The Internet, *my edge router* is The Node -- as long as everything gets to there ok, it's nunya damn business what I do inside. Only what comes out.
That's Why I Have A Router.
Routers don't mangle packets. They route packet and decrement hop counts.
Cheers, -- jra
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
[ me, to Valdis: ]
C'mon; this isn't *your* first rodeo, either. From the viewpoint of The Internet, *my edge router* is The Node -- as long as everything gets to there ok, it's nunya damn business what I do inside. Only what comes out.
That's Why I Have A Router.
Routers don't mangle packets. They route packet and decrement hop counts.
I will remind you, Mark, that routers were originally called *gateways*. That was for a reason. Cheers, -- jra
In message <4680378.4717.1296777587916.JavaMail.root@benjamin.baylink.com>, Jay Ashworth writes:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
[ me, to Valdis: ]
C'mon; this isn't *your* first rodeo, either. From the viewpoint of The Internet, *my edge router* is The Node -- as long as everything gets to there ok, it's nunya damn business what I do inside. Only what comes out.
That's Why I Have A Router.
Routers don't mangle packets. They route packet and decrement hop counts.
I will remind you, Mark, that routers were originally called *gateways*.
And they didn't mangle packets. You either pass through a gateway or not. You don't have your internal organs re-arranged as you go through.
That was for a reason.
Cheers, -- jra
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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:mhuff@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:mpalmer@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.Kletnieks@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
On 2/19/2011 10:11 AM, kmedcalf@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
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_archit... 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, kmedcalf@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
On 2/19/2011 10:11 AM, kmedcalf@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
On Thursday, February 03, 2011 03:59:56 pm Matthew Palmer wrote:
On Thu, Feb 03, 2011 at 03:20:25PM -0500, Lamar Owen wrote:
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.
Yeah, SMTP between servers is peer-to-peer, since both ends can transmit and both ends can receive, using the same protocol, but in different sessions, unlike FTP, where one session needs two streams, and one originates at the file storage end. But it's also used as a client-server protocol between an SMTP sender and an SMTP receiver, which we commonly call the SMTP server. If it were peer-to-peer at that connection there would be no POP3 or IMAP stacks needed to go get the mail, rather, every workstation would receive its mail directly through SMTP. The peer-to-peer nature of SMTP is broken not by NAT, but by dynamically addressed and often disconnected clients, whether their IP addresses are globally routable or not. Sometimes it would be better to get a five day bounce than for the mail to be delivered to the smarthost but the client never picks it up..... There's a reason POP is the Post Office Protocol, as the addresses are then essentially PO Boxes..... But, with my apologies to Moe, Larry, and Curly: "NATagara Falls! Slowly I turned, step by step, inch by inch......" (with a subject of 'quietly' I've been wanting to quote that all thread....) Some are that knee-jerk whenever the Three Letter Acronym That Must Not Be Mentioned is writ large....
On Thu, 03 Feb 2011 17:25:14 EST, Lamar Owen said:
If it were peer-to-peer at that connection there would be no POP3 or IMAP stacks needed to go get the mail, rather, every workstation would receive its mail directly through SMTP.
ETRN (RFC1985) FTW. Just because you don't use it, or don't realize it's there, doesn't mean the protocol doesn't already support it. (Of course, the operational problem with ETRN is that it in fact *does* implement "every workstation gets its mail directly through SMTP", when the actual need is "every *mail recipient*". POP included that whole concept of USER/PASS so you could snarf down the mail queued for one recipient, not one workstation.)
On Thursday, February 03, 2011 05:47:44 pm Valdis.Kletnieks@vt.edu wrote:
ETRN (RFC1985) FTW.
POP (RFC918), and the current version, POP3 (RFC1081) both predate the ETRN RFC: by 12 and 8 years, respectively. By 1996, POP3 was so thoroughly entrenched that ETRN really didn't have a chance to replace POP3 in normal use; of course, there was the point you mention below, too, that makes it less than useful for most e-mail tasks. The ETRN portion, however, introduces the idea of a distinct server and a distinct client that the server holds state for.
(Of course, the operational problem with ETRN is that it in fact *does* implement "every workstation gets its mail directly through SMTP", when the actual need is "every *mail recipient*".
That has its advantages for certain uses. And its distinct disadvantages, as you correctly note, for most 'normal' uses.
On Thu, 03 Feb 2011 15:20:25 EST, Lamar Owen said:
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.
Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed.
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
Subject: Re: quietly.... On Thu, 03 Feb 2011 15:20:25 EST, Lamar Owen said:
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.
Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed.
Wow. $ANONYMOUS_COMMENTER was right: end-to-end isn't an engineering principle, it's a religion. There's nothing inherent in v6 that breaks it, Valdis, just as there was nothing in v4 that broke it. Or NAT44. Or whatever gets deployed for NAT66. If I, as the party responsible for an *end-user edge site*, decide that I do not feel the need to support it *all the way through my edge router*, that is my choice to make. It only affects *end users under my control*, and they're my users to make that decision for. But please don't go on about how the parrot has ceased to be, ok? Cheers, -- jra
On Thu, 03 Feb 2011 17:00:55 EST, Jay Ashworth said:
Wow. $ANONYMOUS_COMMENTER was right: end-to-end isn't an engineering principle, it's a religion.
No, I was commenting on the "FTP is peer-to-peer as both ends initiate connections" (which is true as far as it goes) - but when you look at the bigger context of "what protocols besides VoIP and p2p" it's important. First off, VoIP is merely one special case of peer-to-peer. The second, and more important, point is that if end-to-end is a religion, there is another, even more sizeable religion called "The Internet As A Whole Doesn't Need Any More Than The Small Subset of Protocols I Need For *MY* Network". Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's.
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Thu, 03 Feb 2011 17:00:55 EST, Jay Ashworth said:
Wow. $ANONYMOUS_COMMENTER was right: end-to-end isn't an engineering principle, it's a religion. [ ... ] Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's.
Perhaps. But I think a large part of our disconnect here is that there are lots of backbone-level ops listening to lots of edge-network ops, and failing to take into account that the latter group has *substantially* different constraints on their engineering decisions and practices, and that both groups' limitations are inherent in what they do. Certainly the backbone has to not mess with stuff. But that doesn't mean that edge networks should be *forbidden* from imposing their own restrictions; thos restrictions are (usually) business-based, where backbone decisions must be more engineering-based. Cheers, -- jra
But that doesn't mean that edge networks should be *forbidden* from imposing their own restrictions; thos restrictions are (usually) business-based, where backbone decisions must be more engineering-based.
Cheers, -- jra
Well said, edge needs are virtually always dependent on client demands/realities and while they don't always mesh with elegant engineering they are just as vital. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's.
It really is a different universe for University/ISP versus corporate networks. Neither is wrong or right, but both have different needs. My complaint is that my sense is that Ipv6 was designed and favors the ISP environment rather than corporate networks. A corporate network really does want to ignore next year's new hot protocol unless it makes business sense to support it. There may be regulatory reasons to block it (we are required to archive all email and instant messages) or management may decide it's a waste of time to support or management may feel it's a waste of people's work time to use. Obviously as a end-user with residential FTTH, I want something completely different from my ISP.
----- Original Message -----
From: "Matthew Huff" <mhuff@ox.com>
It really is a different universe for University/ISP versus corporate networks. Neither is wrong or right, but both have different needs. My complaint is that my sense is that Ipv6 was designed and favors the ISP environment rather than corporate networks.
A corporate network really does want to ignore next year's new hot protocol unless it makes business sense to support it. There may be regulatory reasons to block it (we are required to archive all email and instant messages) or management may decide it's a waste of time to support or management may feel it's a waste of people's work time to use. Obviously as a end-user with residential FTTH, I want something completely different from my ISP.
To steal some telco terminology, and tie into my previous reply to Valdis, *what is the demarcation point*? In most cases, it's the edge router. In .edu, it's generally a departmental or resnet router, or even closer to the end workstations than that. But inside the demarc, policy and engineering may -- and nearly always will -- hew to different standards. Cheers, -- jra
Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's= .
It really is a different universe for University/ISP versus corporate netw= orks. Neither is wrong or right, but both have different needs. My complain= t is that my sense is that Ipv6 was designed and favors the ISP environment= rather than corporate networks.
A corporate network really does want to ignore next year's new hot protocol= unless it makes business sense to support it. There may be regulatory reas= ons to block it (we are required to archive all email and instant messages)= or management may decide it's a waste of time to support or management may= feel it's a waste of people's work time to use. Obviously as a end-user wi= th residential FTTH, I want something completely different from my ISP.
This is not necessarily a good reason for taking business policies and using them to engineer a network that _cannot_ work with next year's new hot protocol. If we rewind ten years, you might find that the IP component of many business networks was merely another protocol stack alongside their existing one and a Socks proxy connecting to the Internet which was set up to "enforce policy"; I cannot recall having seen one of these setups survive the last decade. It seemed like a great idea at the time, but didn't really allow for many of the new technologies that businesses now use and rely on. Of course, the best consultants will advise you to implement that type of "great idea", because it means that they'll be seeing you again in a few years when you want your network to support that next new hot protocol. It may be better, however, and also simultaneously less disruptive in the long run, to engineer a network that *can* implement that next, new hot protocol and just use firewall policy to prevent it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On 2/3/2011 4:17 PM, Valdis.Kletnieks@vt.edu wrote:
Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's.
To give them respect, they do have the job of making what currently works keep working in the way they originally engineered them to. Switching to IPv6 should not have had to require any changes from IPv4 outside of a larger address and some minor protocol differences. The support tools to enhance IPv6 beyond IPv4 should be the icing. For example. The CPE side of things and how chaining DHCPv6-PD is still an unfinished product, yet we are saying that everyone should be a go. There are too many configurations and setups out there to make it worth smoothly. We are taking a step backwards from how we do things in IPv4. I'm all for doing away with NAT on CPEs, but the work should have been completed before now on how to properly handle CPEs. The Imperial Geniuses apparently forgot. As for corporate networks, NAT is perfectly fine and they can use it until they need the new protocols we develop. Then they'll have to adapt, but they'll at least already have some of the IPv6 work done. Jack
In message <4D4B2E12.5000504@brightok.net>, Jack Bates writes:
On 2/3/2011 4:17 PM, Valdis.Kletnieks@vt.edu wrote:
Seems there's a lot of engineers out there that only want to make sure last year's protocols work, and are willing to totally ignore next year's.
To give them respect, they do have the job of making what currently works keep working in the way they originally engineered them to.
Switching to IPv6 should not have had to require any changes from IPv4 outside of a larger address and some minor protocol differences. The support tools to enhance IPv6 beyond IPv4 should be the icing.
For example. The CPE side of things and how chaining DHCPv6-PD is still an unfinished product, yet we are saying that everyone should be a go. There are too many configurations and setups out there to make it worth smoothly. We are taking a step backwards from how we do things in IPv4.
The protocol was done in December 2003. Any CPE vendor could have added support anytime in the last 7 years. Did we really need to specify how to daisy chain PD requests when these vendors have been daisy chaining DHCPv4 for various option without any written specification? People have been begging the CPE vendors for IPv6 support for years.
I'm all for doing away with NAT on CPEs, but the work should have been completed before now on how to properly handle CPEs. The Imperial Geniuses apparently forgot.
Seriously. CPE vendors could have release IPv6 capable products that had a stateful firewall, DHCPv6 with prefix delegation 7 years ago. There was *nothing* stopping them except themselves. People have been retrofitting CPE devices to have this functionality for about as long as this.
As for corporate networks, NAT is perfectly fine and they can use it until they need the new protocols we develop. Then they'll have to adapt, but they'll at least already have some of the IPv6 work done.
Jack
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2/3/2011 6:03 PM, Mark Andrews wrote:
The protocol was done in December 2003. Any CPE vendor could have added support anytime in the last 7 years. Did we really need to specify how to daisy chain PD requests when these vendors have been daisy chaining DHCPv4 for various option without any written specification?
NAT definitely made it easier. The same can't be said for DHCPv6-PD. And yes, replacing NAT with a protocol that will handle dissemination of network prefixes deserved having a standards based formula. For CPEs to work well, there must be expectations of what will happen in a number of scenarios so that they can deal with it. For example, will the CPE just hand out /64 networks behind it to other routers? Will it hand out a prefix one longer than what it received and increment up until it's out of space? How does this work in the myriad of ways home users connect things? Cheap CPE routers have come a long way over the last decade. They are probably as close to perfect as you can expect for the price. Now we're just starting over to go through the pains of trying to automate home routers.
Seriously. CPE vendors could have release IPv6 capable products that had a stateful firewall, DHCPv6 with prefix delegation 7 years ago. There was *nothing* stopping them except themselves.
People have been retrofitting CPE devices to have this functionality for about as long as this.
Prefix delegation replaces NAT, but there's no standard for how to divide it up? Sure, people have retrofit it for years. I have myself. However, even in linux, it's a very manual process and involves deciding for yourself how you will hand out prefixes behind the front router. This wasn't a concern with NAT. The most NAT had to worry about was conflicting addresses on the LAN/WAN (and most, these days, will auto renumber if necessary). Jack
In message <4D4B51EA.2030301@brightok.net>, Jack Bates writes:
On 2/3/2011 6:03 PM, Mark Andrews wrote:
The protocol was done in December 2003. Any CPE vendor could have added support anytime in the last 7 years. Did we really need to specify how to daisy chain PD requests when these vendors have been daisy chaining DHCPv4 for various option without any written specification?
NAT definitely made it easier. The same can't be said for DHCPv6-PD. And yes, replacing NAT with a protocol that will handle dissemination of network prefixes deserved having a standards based formula. For CPEs to work well, there must be expectations of what will happen in a number of scenarios so that they can deal with it. For example, will the CPE just hand out /64 networks behind it to other routers? Will it hand out a prefix one longer than what it received and increment up until it's out of space? How does this work in the myriad of ways home users connect things?
Cheap CPE routers have come a long way over the last decade. They are probably as close to perfect as you can expect for the price. Now we're just starting over to go through the pains of trying to automate home routers.
Seriously. CPE vendors could have release IPv6 capable products that had a stateful firewall, DHCPv6 with prefix delegation 7 years ago. There was *nothing* stopping them except themselves.
People have been retrofitting CPE devices to have this functionality for about as long as this.
Prefix delegation replaces NAT, but there's no standard for how to divide it up?
Why does there have to be a standard way to divide it up? You fullfill the request if you can or you ask upstream for more, record the result and add a prefix to the routing table pointing at the requesting device. There done. Even with a /48 you are only going to get to 64000 routes which these devices should be able to handle. In practice it will be a lot less. If you don't have a route you send upstream. The ISP doesn't want to have 64000*customers PD leases so it will return a /48. This matches what's done with IPv4 and NATs. This was blindling obvious to me years ago and should have been to any CPE developer.
Sure, people have retrofit it for years. I have myself. However, even in linux, it's a very manual process and involves deciding for yourself how you will hand out prefixes behind the front router. This wasn't a concern with NAT. The most NAT had to worry about was conflicting addresses on the LAN/WAN (and most, these days, will auto renumber if necessary).
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2/3/2011 7:50 PM, Mark Andrews wrote:
This was blindling obvious to me years ago and should have been to any CPE developer.
It doesn't appear to be blindingly simple for the cpe-router-bis draft, which leaves it as TBD, or the cpe-router draft which also is silent. General consensus I got from v6ops was that IAIDs won't be utilized by CPE routers, which means they don't expect your requesting upstream logic. In fact, they didn't seem to like any of my ideas on versatility for handling this job, which means we'll likely have interoperability problems between CPE manufacturers. Jack
In message <4D4B5DCB.3090909@brightok.net>, Jack Bates writes:
On 2/3/2011 7:50 PM, Mark Andrews wrote:
This was blindling obvious to me years ago and should have been to any CPE developer.
It doesn't appear to be blindingly simple for the cpe-router-bis draft, which leaves it as TBD, or the cpe-router draft which also is silent. General consensus I got from v6ops was that IAIDs won't be utilized by CPE routers, which means they don't expect your requesting upstream logic.
Well the DHCP server has to support multiple IAID's as that is how it is spec'd. A DHCP server that doesn't do this is broken. There doesn't have to be consensus in this area because it does not matter. Different vendors can choose different solutions to how they make upstream requests.
In fact, they didn't seem to like any of my ideas on versatility for handling this job, which means we'll likely have interoperability problems between CPE manufacturers.
Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In a corporate environment, that's the way it's been for almost 30 years. The feeling I get is that people want to re-litigate that with Ipv6, and make every desktop an end-to-end node. Not going to happen. In most corporate environments, even with sarcasm, you are right. There are clients and there are servers there are no such things as nodes. This is a major reason there is very little deployment of ipv6 within corporate networks. Things like DHCPv6 integrated with NAC/802.1x, RA Guard, etc are another. Oh, and telling everyone that all server addresses had to be dynamic and determined by your ISP (PA space) was another funny. Again, not going to happen. We have PI space and are testing Ipv6, but still waiting on consistent support from all Oses in use (Solaris, Linux and various flavors of Windows). Things like address token support (works fine in Solaris, I assume it's available somewhere in Linux but can't find it), and not available at all with Windows.
-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Thursday, February 03, 2011 4:47 PM To: Lamar Owen Cc: nanog@nanog.org Subject: Re: quietly....
On Thu, 03 Feb 2011 15:20:25 EST, Lamar Owen said:
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.
Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed.
On Thu, 3 Feb 2011, Valdis.Kletnieks@vt.edu wrote:
Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed.
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. No one is going to check out their neighbors website running on their neighbors computer if the neighbor didn't make an effort to make their computer a server (by assigning DNS, running server software, etc) regardless of NAT etc etc. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Feb 3, 2011, at 3:14 PM, david raistrick wrote:
On Thu, 3 Feb 2011, Valdis.Kletnieks@vt.edu wrote:
Well, it's official - the original end-to-end design principal of the Internet is dead, deceased, and buried. Henceforth, there will be Clients, and there will be Servers, and all nodes will be permanently classified as one or the other, with no changing or intermixing of status allowed.
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 on the end-to-end model and accepted that some innovations simply wouldn't happen for a while. That doesn't mean we want to make that tradeoff or those limitations permanent.
No one is going to check out their neighbors website running on their neighbors computer if the neighbor didn't make an effort to make their computer a server (by assigning DNS, running server software, etc) regardless of NAT etc etc.
So? That's an extremely narrow view of the potential applications of restored globally unique host addressing. Owen
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 ago....maybe 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 raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
In message <alpine.BSF.2.00.1102041250570.54349@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 ago....maybe 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: marka@isc.org
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 raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
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 rali@tifosi.com "A polar bear is just another way of expressing a rectangular bear"
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
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 ago....maybe 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
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
On Feb 4, 2011, at 5:26 PM, Jack Bates wrote:
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
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. Owen
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
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.
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
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
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
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
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.
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
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. 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
sure ................ ________________________________ From: Lee Howard <lee@asgard.org> To: Owen DeLong <owen@delong.com>; david raistrick <drais@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.
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
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. 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
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
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...
On Fri, Feb 4, 2011 at 11:38, <Valdis.Kletnieks@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
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
Subject: 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...
Yes, yes; and the first rule of Tautology Club is the first rule of Tautology Club. Cheers, -- jra
On Thu, 3 Feb 2011, Valdis.Kletnieks@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.
Speaking of should-have-died-years-ago. FTP fits that category well. ;)
I'm told that IPSEC through a NAT can be interesting too... And that's something I'm also told some corporations are interested in.
NAT traversal for ipsec was sorted out more than a few years ago with 3 or 4 different methods in play. I dropped out of that market about the time it came to light, but as a ipsec end user I haven't had NAT problems going back as far as 2006 for sure, possibily further. (the original problem was that only 1 user behind 1 IP could speak ipsec because it uses a specific protocol, not a port, that can only be 1-to-1. I'll leave it as an exercise for the reader to figure out that was magiced around without requiring the NAT devices to do anything. and ssl doesn't count. :) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote:
This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.
So does any decent stateful inspection firewall. That's why your argument doesn't hold water.
Perhaps we disagree on the definition of "decent". An SPI Firewall is code, running on a router. It drops packets which should not otherwise be routed by the base routing code running on that router, which knows how to reach the internal network's addresses, and packets are sent to it from the Net-at-large. In the NAT4 case, those internal addresses are unknown to the NAL, and the NAT code, as configured by the person operating the edge router, is the only way for packets to get into the LAN; if the NAT code falls over on the router, then packets cannot get in, since the outside world *cannot get packets to that router with addresses which it will further route inbound*. That's the expansion of "fails safe". Let us now examine the alternate case. In this case, that original SPI case I mentioned above, we're assuming routable addresses behind that firewall -- that is, the NAL *does* know how to aim packets at a *specific host inside my LAN*. Those packets get to my edge router, and the SPI firewall drops the appropriate packets before they're actually handed to the routing core, and sent inwards. If the firewall code fails or is inadvertanly turned off, what happens? Why, the router does what it's designed for, it routes. Those external packets. In, to my hosts. With no firewall in the way. Sorry to have to show my work, but that's my work: please explain how you feel that those two situations do *not* make NAT safer in the edge case where an SPI firewall fails in such a fashion as not to drop the packets asked of it? All that's necessary to cause that failure is to say "turn it off", whereas causing a comparable failure on the NAT side requires *defining specific new rules that target specific internal hosts by IP address*, which is a much more complex task, which effectively cannot be accomplished by accident, unlike accidentally disabling a firewall. Cheers, -- jra
On 3 feb 2011, at 20:09, Jay Ashworth wrote:
That's the expansion of "fails safe".
You conviently overlook my earlier message about this. But sure, let's assume that at some point, some packets from the outside manage to pass through to the inside in the IPv6 case. So how does anyone know where to send these packets in the first place? And if they do, what bad effects exactly do packets coming from the outside have? Ping of death has been fixed a loooong time ago. And you assume that NATs block packets very well. They don't. First of all, there's uPNP IGD and NAT-PMP. Depending on the type of NAT, the bindings are quite loose and allow lots of additional packets that don't belong to the NATed sessions in. After all, NATs only break incoming sessions by accident. Firewalls do this on purpose, so they do a much better job. If you really want to be safe, you should completely disconnect your network. Or at the very least not run any code, such as javascript and java, that comes in over the network. This is one of the biggest sources of real-world infections. Incoming packets haven't been since about the slammer worm era.
This thread makes me sad. adam. On 03/02/2011 19:09, Jay Ashworth wrote:
----- Original Message -----
From: "Owen DeLong"<owen@delong.com> On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote:
This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.
So does any decent stateful inspection firewall. That's why your argument doesn't hold water. Perhaps we disagree on the definition of "decent".
An SPI Firewall is code, running on a router. It drops packets which should not otherwise be routed by the base routing code running on that router, which knows how to reach the internal network's addresses, and packets are sent to it from the Net-at-large.
In the NAT4 case, those internal addresses are unknown to the NAL, and the NAT code, as configured by the person operating the edge router, is the only way for packets to get into the LAN; if the NAT code falls over on the router, then packets cannot get in, since the outside world *cannot get packets to that router with addresses which it will further route inbound*.
That's the expansion of "fails safe".
Let us now examine the alternate case.
In this case, that original SPI case I mentioned above, we're assuming routable addresses behind that firewall -- that is, the NAL *does* know how to aim packets at a *specific host inside my LAN*.
Those packets get to my edge router, and the SPI firewall drops the appropriate packets before they're actually handed to the routing core, and sent inwards.
If the firewall code fails or is inadvertanly turned off, what happens?
Why, the router does what it's designed for, it routes. Those external packets. In, to my hosts. With no firewall in the way.
Sorry to have to show my work, but that's my work: please explain how you feel that those two situations do *not* make NAT safer in the edge case where an SPI firewall fails in such a fashion as not to drop the packets asked of it?
All that's necessary to cause that failure is to say "turn it off", whereas causing a comparable failure on the NAT side requires *defining specific new rules that target specific internal hosts by IP address*, which is a much more complex task, which effectively cannot be accomplished by accident, unlike accidentally disabling a firewall.
Cheers, -- jra
On 3 feb 2011, at 17:16, Jon Lewis wrote:
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too? Or do you propose to make IPv6 home gateways the same way IPv4 home gateways work, where it's usually not even possible to turn it off? Consumer systems need to be able to function without a firewall device, anyway. Who brings a firewall to a wifi hotspot, or puts one between his laptop and 3G adapter? I'm perfectly happy with an IPv6 network that only has rational people on it while those who insist on NAT stay behind on IPv4.
On Thu, 3 Feb 2011, Iljitsch van Beijnum wrote:
On 3 feb 2011, at 17:16, Jon Lewis wrote:
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too?
Outbound traffic would. Inbound, if on the inside, you're using IPv6 space that's not globally routed, won't. Just like what happens now with NAPT with rfc1918 space on the inside when you stop doing translation...private IP traffic leaks out...but nothing comes back because there is no return path. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 3 feb 2011, at 17:40, Jon Lewis wrote:
Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too?
Outbound traffic would. Inbound, if on the inside, you're using IPv6 space that's not globally routed, won't. Just like what happens now with NAPT with rfc1918 space on the inside when you stop doing translation...private IP traffic leaks out...but nothing comes back because there is no return path.
Don't be so sure. Just like I can set my Airport base station up for NAT or bridge mode now, in a NAT66 future there would be a choice between "obtain addresses from ISP and advertise them on the LAN side" and "obtain addresses from ISP, advertise ULAs on the LAN side and translate". So if the setting gets flipped from the latter to the former you're still wide open.
Yes, but unless that ipv6 that isn't globally routed is NAT66 to the outside world, then it wouldn't have external access.
-----Original Message----- From: Jon Lewis [mailto:jlewis@lewis.org] Sent: Thursday, February 03, 2011 11:41 AM To: Iljitsch van Beijnum Cc: nanog@nanog.org Subject: Re: quietly....
On Thu, 3 Feb 2011, Iljitsch van Beijnum wrote:
On 3 feb 2011, at 17:16, Jon Lewis wrote:
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too?
Outbound traffic would. Inbound, if on the inside, you're using IPv6 space that's not globally routed, won't. Just like what happens now with NAPT with rfc1918 space on the inside when you stop doing translation...private IP traffic leaks out...but nothing comes back because there is no return path.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 2/3/2011 10:30 AM, Iljitsch van Beijnum wrote:
Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too?
Only if the ISP is routing your inside address space to the firewall.
Or do you propose to make IPv6 home gateways the same way IPv4 home gateways work, where it's usually not even possible to turn it off?
Home gateways don't need NAT. It's a balancing act between what is acceptable to break and what isn't. You wouldn't put uPNP on a corporate firewall either (but it's necessary for home gateways even without NAT).
I'm perfectly happy with an IPv6 network that only has rational people on it while those who insist on NAT stay behind on IPv4.
I'm perfectly happy with watching the Internet go to hell; as it has been, and IPv6 will just escalate it. :) Jack
On Thu, Feb 03, 2011 at 10:47:50AM -0600, Jack Bates wrote:
On 2/3/2011 10:30 AM, Iljitsch van Beijnum wrote:
I'm perfectly happy with an IPv6 network that only has rational people on it while those who insist on NAT stay behind on IPv4.
I'm perfectly happy with watching the Internet go to hell; as it has been, and IPv6 will just escalate it. :)
I am intrigued by your ideas, and wish to subscribe to your newsletter. Actually, I must agree that since I've stopped doing IT work professionally, I've found myself far less emotionally invested in this kind of thing, and far less worried about the world ending (which, let's face it, it rarely does). Does wonders for the blood pressure. - Matt
On 2/3/2011 2:12 PM, Matthew Palmer wrote:
Actually, I must agree that since I've stopped doing IT work professionally, I've found myself far less emotionally invested in this kind of thing, and far less worried about the world ending (which, let's face it, it rarely does). Does wonders for the blood pressure.
I used to say that if I won the lottery, I'd still keep my job (as I love it). Dealing with IPv6 and the fact that decades apparently isn't enough for a standards body and a small set of corporations to design and implement a protocol which needs to do everything the old one did (minimum) and more (advisable), I've recently reconsidered. Here's to winning the Lottery. Then I won't need the Internet. :) jack
----- Original Message -----
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
On 3 feb 2011, at 17:16, Jon Lewis wrote:
When someone breaks or shuts off that filter, traffic through the NAPT firewall stops working. On the stateful firewall with public IPs on both sides, everything works...including the traffic you didn't want.
People are going to want NAT66...and not providing it may slow down IPv6 adoption.
Hm, if you turn off the NAT66 function, wouldn't the traffic pass through unhindered, too?
Or do you propose to make IPv6 home gateways the same way IPv4 home gateways work, where it's usually not even possible to turn it off?
I think the implication includes available 1918-like space to use behind the NAT which is similarly publicly non-routable; *this* is the part we care about -- that those addresses are only accessible *to the edge router*. Cheers, -- jra
On Thu, 3 Feb 2011, Brian Johnson wrote:
1) To allow yourself to change or maintain multiple upstreams without renumbering.
Not sure what you mean here. So having PI space can't accomplish this?
Using PI space means paying significantly more money per year than using PA space, particularly if you factor in the "recommended" subnet sizing and that your v6 address space requirements signficantly increase over v4+NAT. Remember that we're not talking about ISPs and large enterprises who are used to shelling out artifically inflated $$ per year to use PI space. We're talking about telling folks who were happy using PA space (or who have PI space from before IANA) that they now have to rent addresses if they want to avoid internal renumbering.
6) Because you have allocated a single address to a machine that later on actually represents n differerent actual network entities, and retrofitting them with their own unique IPv6 subnet presents a problem.
Huh?
I understood that. I have a customer in my datacenter with 50 servers behind a firewall. (that "customer" could be an internal team at my enterprise, or a customer at a colo, or even a customer at the end of a telco circuit). I need to renumber. The coordination effort involved in renumbering @ the firewall, vs renumbering the -entirety- of the customer's internal subnets is significant. One customer side example? Oracle RAC. With v4 and NAT, RAC would never have to know anything. With no NAT, I have to shut down RAC, shut down OCFS2, reconfigure the cluster filesystem (which is a nontrival task with nontrival risk), reconfigure RAC (which goes OK, other than that I have to reconfigure potentially a half dozen config files on every server that connects to it), restart ocfs, restart RAC.... That's all new work, because I told my customer they cannot use NAT. And I have to do that with -every- customer. With v4, I just helped the customer configure his firewall to support both the old and new addresses, changed external facing DNS, waited for all traffic to move over, removed the old addresses, and we were done. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
In message <3CD3A697-8D3C-4EDE-8E4E-53C0E103E12C@sackheads.org>, John Payne writes:
On Feb 2, 2011, at 2:54 PM, Owen DeLong wrote:
=20 On Feb 2, 2011, at 11:40 AM, John Payne wrote: =20
=20 On Feb 2, 2011, at 6:18 AM, Owen DeLong wrote: =20
NAT66 is different. NAT66 breaks things in ways that impact sites = outside of the site choosing to deploy NAT. =20 Examples? =20 SIP Network enabled Video Games Peer to Peer services of various forms etc.
I chose NAT66. How does that affect you or any other site?
Note that I have already blocked games and peer to peer either = technically or via policy.... and I have no SIP end points that have any = business talking outside the enterprise.
Today you don't. Tomorrow you might.
Just rephrasing you slightly. NAT66 will break applications that many = enterprises will already have blocked at their perimeters.
And it makes applications they do use (current and future) more complicated as they have to deal with all the issues that arise from using a NAT'd address. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Ditto. -----Original Message----- From: Jack Bates [mailto:jbates@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
On 2 feb 2011, at 4:51, Dave Israel wrote:
They were features dreamed up by academics, theoreticians, and purists, and opposed by operators.
Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.) There is a fundamental difference between designing something and using something. Both inform the other. But letting users with no design experience create something is a short road to failure. (Letting designers run stuff isn't much better.) I always like to say the internet is an infinite universe. In an infinite universe, everything that's possible exist. Same in the internet. Think of some way to do something, however ill-informed, and someone is doing it that way. 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. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
On Feb 2, 2011, at 12:16 AM, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 4:51, Dave Israel wrote:
They were features dreamed up by academics, theoreticians, and purists, and opposed by operators.
Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.)
There is a fundamental difference between designing something and using something. Both inform the other. But letting users with no design experience create something is a short road to failure. (Letting designers run stuff isn't much better.)
I always like to say the internet is an infinite universe. In an infinite universe, everything that's possible exist. Same in the internet. Think of some way to do something, however ill-informed, and someone is doing it that way.
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. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace. So, your clear win has proven to be a rather large lose in a number of environments. Owen
On 2 feb 2011, at 12:39, Owen DeLong wrote:
I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace.
I didn't say they were necessarily good routers. The issue of rogue routers and DHCP servers is a separate one. Obviously if you have rogue RAs but no rogue DHCPv6 then it helps if you can ignore the RAs and put all the info in DHCPv6. But the same bad practices that created rogue RAs can just as easily create rogue DHCPv6 servers so this is not a real solution, just very limited managing of symptoms. But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
On Feb 2, 2011, at 4:50 AM, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 12:39, Owen DeLong wrote:
I would point to 6to4 and the RAs coming from Windows Laptops that think they are routers because someone clicked on an ICS checkbox as a counter example that letting things that think they are routers announce their presence is, in fact, proof that it is not only possible that something goes wrong, but, commonplace.
I didn't say they were necessarily good routers.
No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not.
The issue of rogue routers and DHCP servers is a separate one. Obviously if you have rogue RAs but no rogue DHCPv6 then it helps if you can ignore the RAs and put all the info in DHCPv6. But the same bad practices that created rogue RAs can just as easily create rogue DHCPv6 servers so this is not a real solution, just very limited managing of symptoms.
It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue. Unfortunately because administrators don't have that option, we're stuck.
But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
This is a clear example of the myopia in the IETF that has operators so frustrated. Owen
On 2 feb 2011, at 14:10, Owen DeLong wrote:
I didn't say they were necessarily good routers.
No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not.
If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6.
It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue.
And who overrides the rogue DHCPv6 messages? Or is it turtles all the way down?
But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
This is a clear example of the myopia in the IETF that has operators so frustrated.
I can assure you that I'm quite alone within the IETF with that view. I'm not talking about the interaction between DHCPv6 and RAs here, just about how bad DHCPv6 is on its own terms. For instance, there's no client identifier or using MAC addresses to identify clients, this is now done with a DUID. Unfortunately, administrators have no way of knowing what DUID a given client is going to use so having a DHCPv6 server set up with information tailored to a specific client is really hard. There's also stateful and stateless DHCPv6, but it's the client that has to choose between them, while the server knows whether it's going to return stateful or stateless information. There's no prefix length in DHCPv6, so this needs to be learned from RAs. (Although it can be argued that because routers need to know this info anyway, having the prefix length there doesn't buy you anything.) The problem with DHCP in general is that there is a continuous influx of new options but they all need to be encoded into a binary format inside a small packet. This info should be in an XML file on a HTTP server instead, rather than be overloaded into the connectivity bootstrapping. The problem with RA / DHCP is that RAs were built with some vague notion of what DHCP would do some day and then when DHCPv6 was developed half a decade later the evolving ideas didn't fit with the shape of the hole left in RAs anymore but that problem wasn't addressed at this time. Fixing that now (hopefully fixing it well, not doing stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we all suffer every day) means that we'll end up with three types of systems: - no DHCPv6 - legacy DHCPv6 - new DHCPv6 Good luck trying to come up with a combination of RA and DHCP settings that make all three work well. Even without new DHCPv6, there's already 12 ways to set up RAs and DHCP and only a few combinations produce useful results.
Once upon a time, Iljitsch van Beijnum <iljitsch@muada.com> said:
If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6.
The difference is that in the widest-used desktop OS, "turn me into a router" is a single checkbox, while "turn me into a DHCP server" requires installing software. The first is an accident waiting to happen (and then a support nightmare), while the second is not a common problem. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Wed, Feb 2, 2011 at 09:49, Chris Adams <cmadams@hiwaay.net> wrote:
The difference is that in the widest-used desktop OS, "turn me into a router" is a single checkbox, while "turn me into a DHCP server" requires installing software.
Turning on Internet Connection Sharing also (helpfully) enables and configures a DHCP server on the ICS host. ~Matt
On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 14:10, Owen DeLong wrote:
I didn't say they were necessarily good routers.
No, you said the router always knows better than the DHCP server. This is an example of a common case where it does not.
If someone turns their box into a router they can also turn it into a DHCP server. This is what happens with IPv4. The solution is to filter these packets from fake routers in the switches. So ask your switch vendor for that feature in IPv6.
Turns out that this is A LOT less common and when it does happen, it's easier to find and eliminate.
It really isn't. If the DHCP server on a subnet could override the rogue routers RA messages by policy, then, it would actually make it fairly trivial to address this issue.
And who overrides the rogue DHCPv6 messages? Or is it turtles all the way down?
Turns out to be quite a bit easier to isolate and remove the rogue DHCP server. Also turns out that there isn't a single-checkbox way to accidentally create a DHCP server, unlike a rogue RA.
But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
This is a clear example of the myopia in the IETF that has operators so frustrated.
I can assure you that I'm quite alone within the IETF with that view.
Then you have had impressive success at blocking useful development for a lone individual.
I'm not talking about the interaction between DHCPv6 and RAs here, just about how bad DHCPv6 is on its own terms. For instance, there's no client identifier or using MAC addresses to identify clients, this is now done with a DUID. Unfortunately, administrators have no way of knowing what DUID a given client is going to use so having a DHCPv6 server set up with information tailored to a specific client is really hard. There's also stateful and stateless DHCPv6, but it's the client that has to choose between them, while the server knows whether it's going to return stateful or stateless information. There's no prefix length in DHCPv6, so this needs to be learned from RAs. (Although it can be argued that because routers need to know this info anyway, having the prefix length there doesn't buy you anything.)
I agree that there is much that needs to be improved in DHCPv6. The lack of a default router, however, is the broken part that causes the most difficulty in modern operations.
The problem with DHCP in general is that there is a continuous influx of new options but they all need to be encoded into a binary format inside a small packet. This info should be in an XML file on a HTTP server instead, rather than be overloaded into the connectivity bootstrapping. The problem with RA / DHCP is that RAs were built with some vague notion of what DHCP would do some day and then when DHCPv6 was developed half a decade later the evolving ideas didn't fit with the shape of the hole left in RAs anymore but that problem wasn't addressed at this time. Fixing that now (hopefully fixing it well, not doing stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 DHCP problems that we all suffer every day) means that we'll end up with three types of systems:
We can agree to disagree about that. While it's true that there is a large number of options and the DHCP packet needs to remain relatively small, the reality is that no site uses all of them. They large number of options represents a superset of the differing needs of various sites. XML on HTTP is too much overhead for things a system needs to know at boot time to download its kernel. Operationally, DHCPv4 is just fine and is meeting the needs today. There's no reason we shouldn't have at least equivalent functionality in DHCPv6.
- no DHCPv6 - legacy DHCPv6 - new DHCPv6
Good luck trying to come up with a combination of RA and DHCP settings that make all three work well. Even without new DHCPv6, there's already 12 ways to set up RAs and DHCP and only a few combinations produce useful results.
Yes... It really would be better if both SLAAC and DHCPv6 provided complete solutions and the operator could pick the single solution that worked best for them. Unfortunately, instead of looking at how things are used in the real world, IETF pursued some sort of theoretical purity exercise and we have two half-protocols that can't possibly provide a complete solution in either one. 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. DHCP fails because you can't get a default router out of it. Owen
On Wed, 2011-02-02 at 07:00 -0800, 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.
DHCP fails because you can't get a default router out of it.
That said, there appear to be efforts under way to add DNS server information to RA and to add a default router option to DHCPv6. Well, last time I looked, anyway... Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
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.
On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote:
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.
Been there. Done that. Made perfect business sense. The NTP servers were ours and kept excellent time. Oh, we also included the default route. James R. Cutler james.cutler@consultant.com
Hi,
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
So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ?? Or let me guess, I should hardcode some public DNS servers which I can hopefully reach from where I am, hopefully is not down or having issues and hopefully I don't have poor latency to? And here I always thought the D in DHCP stood for Dynamic.
On 2 feb 2011, at 16:35, Greg Estabrooks wrote:
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
So, when I take my laptop from Home to work, to the airport, to some random cyber cafe I should have to manually alter my DNS servers assuming I can find someone in the location who can tell me what they are ??
No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
On 2/2/2011 9:52 AM, Iljitsch van Beijnum wrote:
I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
I don't disagree that an anycast well known address would be nice for say RA + SLAAC. However, DHCP has many uses and requirements. It has versatility that RA + SLAAC doesn't have, especially when dealing with policies for specific devices (which I understand DHCPv6 is missing some of this logic). This includes DNS servers. When I am connected to certain parts of our network, the DNS servers I receive are not the same as everyone around me. This applies to VPN connections as well (though I realize in VPN I could actually setup for the prefix to go via the VPN). DHCP is about giving hosts information based on policies. The simpler use of DHCP could easily be replaced, but the more common corporate uses cannot. Currently, much of the functionality of DHCP is not included in DHCPv6, which is a serious operations issue. Jack
On 2/2/2011 10:52 AM, Iljitsch van Beijnum wrote:
No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.)
I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
So what if I want to assign different people to different resolvers by policy? What if I want to use non-/64 subnets with a resolver on each one? What if I round-robin amongst more or less resolvers than there are well-known addresses assigned to? What if, in 1/2/5/10/20/50 years, we need to do things differently? Why intentionally burden a protocol with something that screams "I am going to be a depreciated legacy problem someday!" -Dave
On 2 feb 2011, at 17:14, Dave Israel wrote:
I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
So what if I want to assign different people to different resolvers by policy?
For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill. Also, the examples mentioned are about enterprise networks with stable systems. Here, DHCP works well. However, with systems that connect to different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea.
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea.
It's not "random" if the network operator is providing it via DHCP is it? Antonio Querubin e-mail/xmpp: tony@lava.net
On Wed, 02 Feb 2011 07:45:46 -1000, Antonio Querubin said:
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea.
It's not "random" if the network operator is providing it via DHCP is it?
If you're connecting at a Starbuck's, and you care more than "hopefully somebody will tell me the right time within a minute", yes, it *is* essentially random.
On Feb 2, 2011, at 11:42 AM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 02 Feb 2011 07:45:46 -1000, Antonio Querubin said:
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea.
It's not "random" if the network operator is providing it via DHCP is it?
If you're connecting at a Starbuck's, and you care more than "hopefully somebody will tell me the right time within a minute", yes, it *is* essentially random.
While that is true, the people that are asking for the ability to advertise NTP servers in DHCP are not running the networks at Starbucks. Owen
On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 2 feb 2011, at 17:14, Dave Israel wrote:
I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
So what if I want to assign different people to different resolvers by policy?
For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill.
There are all sized enivronments. Political battles having partly crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake into large enterprise organizations ... it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls. As an active consultant to medium and large enterprises, this is driving me nuts. This single item is in my estimation contributing at least 6, perhaps 12 months to the worldwide average delay in IPv6 uptake. I know several organizations that would have been there six months ago had DHCPv6 not had this flaw. They're currently 6-12 months from getting there. This was predicted. That the right people didn't believe it suggests that perhaps the right people are the wrong people.
Also, the examples mentioned are about enterprise networks with stable systems. Here, DHCP works well. However, with systems that connect to different networks, things don't always work so well. I may want to use the DHCP-provided NTP servers at work, but syncing with a random NTP server when I connect to a wifi hotspot is not such a great idea.
That's a problem with insufficiently configurable network location profiles on your OS (not having a "listen to DHCP NTP here, but not elsewhere" button). -- -george william herbert george.herbert@gmail.com
On Feb 2, 2011, at 3:15 PM, George Herbert wrote:
On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 2 feb 2011, at 17:14, Dave Israel wrote:
I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done.
So what if I want to assign different people to different resolvers by policy?
For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is intended as a stateful configuration provisioning tool, i.e., to give different hosts different configurations. If that's what you need then DHCP fits the bill. However, in most small scale environments this is not what's needed so DHCP doesn't fit the bill.
There are all sized enivronments. Political battles having partly crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake into large enterprise organizations ... it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls. As an active consultant to medium and large enterprises, this is driving me nuts.
This single item is in my estimation contributing at least 6, perhaps 12 months to the worldwide average delay in IPv6 uptake. I know several organizations that would have been there six months ago had DHCPv6 not had this flaw. They're currently 6-12 months from getting there.
Well, to be fair... In my "decent sized" enterprise, DHCPv6 and the lack of default route is irritating but not the blocker. The second largest OS we have doesn't support DHCPv6 at all, so its not like fixing the default route option is a magic bullet. So, we're going to have DHCP for IPv4 and SLAAC for IPv6 for now. DNS, NTP, etc will be done over IPv4 - no way around that. We have vendor struggles. The current pain is the lack of good support for VRRPv3. RA guard is another. However, IPv6 on the enterprise network will continue to be seen as an after thought until and unless we get parity.
In message <09C9D1B8-F003-4932-ABC1-7299F81F1C29@sackheads.org>, John Payne writes:
On Feb 2, 2011, at 3:15 PM, George Herbert wrote:
On 2 feb 2011, at 17:14, Dave Israel wrote: =20
I understand people use DHCP for lots of stuff today. But that's =
=20
So what if I want to assign different people to different resolvers = by policy? =20 For the record: I'm not saying that DHCPv6 is never useful. DHCPv6 is = intended as a stateful configuration provisioning tool, i.e., to give = different hosts different configurations. If that's what you need then = DHCP fits the bill. However, in most small scale environments this is = not what's needed so DHCP doesn't fit the bill. =20 There are all sized enivronments. Political battles having partly crippled DHCPv6 in ways that end up significantly limiting IPv6 uptake into large enterprise organizations ... it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls. As an active consultant to medium and large enterprises, this is driving me nuts. =20 This single item is in my estimation contributing at least 6, perhaps 12 months to the worldwide average delay in IPv6 uptake. I know several organizations that would have been there six months ago had DHCPv6 not had this flaw. They're currently 6-12 months from getting
On Wed, Feb 2, 2011 at 8:55 AM, Iljitsch van Beijnum = <iljitsch@muada.com> wrote: mainly because DHCP is there, not because it's the best possible way to = get that particular job done. there.
Well, to be fair... In my "decent sized" enterprise, DHCPv6 and the lack = of default route is irritating but not the blocker. The second largest OS we have doesn't support DHCPv6 at all, so its not = like fixing the default route option is a magic bullet.
So complain to the OS vendor. DHCPv6 should be there. DHCPv6 is many years old now. It's been part of the configuration model for a node for over a decade.
So, we're going to have DHCP for IPv4 and SLAAC for IPv6 for now. DNS, = NTP, etc will be done over IPv4 - no way around that.
We have vendor struggles. The current pain is the lack of good support = for VRRPv3. RA guard is another.=20
However, IPv6 on the enterprise network will continue to be seen as an = after thought until and unless we get parity.= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
From: Iljitsch van Beijnum <iljitsch@muada.com>
I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way >to get that particular job done.
I don't particularly care whether DHCP is the *best* way to get some particular job done; I care that it is a well-known, well-understood way of *getting* the job done, and lots of operational work, development, and process has gone into making DHCP do this well, reliably, and scalably. The problem with DHCPv6 is that it doesn't do nearly enough when compared to DHCPv4, and there are not in fact any good alternatives. The insistence on RA, along with a handwaving dismissal of all of those folks who have a high reliance on DHCP has done a tremendous disservice to the uptake of IPv6. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On Wednesday, February 02, 2011 10:52:46 am Iljitsch van Beijnum wrote:
No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.)
Hrmph. Shades of 47.007900000000000000000000.00A03E000001.00 and all that that implies, here. Well, different syntatic sugar, but, anyway.... Haven't we withdrawn from this ATM before?
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.)
Because no one has ever had a need to coexist with other DNS servers on the same subnet, right? After all, there should only ever be 1 authorative source of information, and there's no way we would ever want to have an exception for that. ...david (who manages his own authorative and recursive DNS servers that are used specificly for our group's purposes that have to coexist with IT-managed servers) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Wed, Feb 2, 2011 at 12:28, david raistrick <drais@icantclick.org> wrote:
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
No, the point is that DNS resolvers in different places all use the same
addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.)
Because no one has ever had a need to coexist with other DNS servers on the same subnet, right? After all, there should only ever be 1 authorative source of information, and there's no way we would ever want to have an exception for that.
Why do they have to be mutually exclusive? What's wrong with having default well known (potentially anycasted) resolver addresses, which can then be overridden by RA/DHCP/static configuration? ~Matt
On 02/02/2011 17:43, Matt Addison wrote:
Why do they have to be mutually exclusive? What's wrong with having default well known (potentially anycasted) resolver addresses, which can then be overridden by RA/DHCP/static configuration?
because that increases the complexity of the system, and complexity leads to more failure modes. If you model how this would work on a state diagram, you'll see that there are several inherent ways that this will cause serious problems when people start doing things like removing the well known addresses (because they don't use them), and so forth. This is a well-examined problem: well known unicast listener addresses are a bad, bad idea. Nick
On 03/02/2011 14:15, Jack Bates wrote:
Is this why the root isn't just using well-known?
No - that's pretty much the only situation where you have a technical requirement to hardcode IP address, and there's basically no way of getting around it. Besides, it's completely different to having a requirement that all locally connected machines should by default send all of their DNS requests to a specific address. You're talking about a situation which affects only DNS resolvers. I'm talking about something which affects all end-user nodes in the world. i.e. much messier problem on a completely different scale. Nick
On 2/3/2011 8:20 AM, Nick Hilliard wrote:
On 03/02/2011 14:15, Jack Bates wrote:
Is this why the root isn't just using well-known?
No - that's pretty much the only situation where you have a technical requirement to hardcode IP address, and there's basically no way of getting around it.
Besides, it's completely different to having a requirement that all locally connected machines should by default send all of their DNS requests to a specific address. You're talking about a situation which affects only DNS resolvers. I'm talking about something which affects all end-user nodes in the world. i.e. much messier problem on a completely different scale.
You missed my pointed. Root servers are hard coded, but they aren't using a well known anycast address. Jack
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... Regards, -drc
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
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
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
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
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
On Wed, Feb 2, 2011 at 10:23, Iljitsch van Beijnum <iljitsch@muada.com>wrote:
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.
I'll admit right now that I don't know nearly enough about the IETF process, but it looks like there have been 2 separate attempts at this: draft-lee-dnsop-resolver-wellknown-ipv6addr - ID, expired draft-ohta-preconfigured-dns - ID, expired Until one of those is revived (or a similar draft is written), and makes it through IETF to reach RFC status, and there are assigned addresses from IANA, there are no well known addresses for anyone hardcode. ~Matt
On 2/2/2011 9:23 AM, Iljitsch van Beijnum wrote:
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.
Most corporate networks do, as it is more critical for the workstations to be in sync with the servers than to actually have the correct time. Though ideally, the servers have their time synced in one form or another.
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.
Administrative control. Utilizing well known addresses and anycasting DNS servers is considered a BAD thing. Anycasting in this way means you always use the nearest DNS server, which may NOT be the correct DNS server for your machine.
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.
It is wrong in many situations. Case in point. As an ISP, RA does not gain me anything but increases router load and bandwidth utilization as it spits out to 3000+ interfaces periodically. Default Router in DHCPv6 reduces this load and traffic. Another case: What is the authentication model on RAs? M$ is very good at authenticating their DHCP servers to insure rogues don't interfere. Jack
On 2/2/11 7:23 AM, Iljitsch van Beijnum wrote:
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.
Me, because I have better things to do than to manually enter NTP servers (and other various boot settings) into all of my IP phones by hand. Configure DHCP, plug them in, and it just works. ~Seth
On Feb 2, 2011, at 10:23 AM, Iljitsch van Beijnum wrote:
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.
Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong.
On 2 feb 2011, at 20:37, John Payne wrote:
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.
Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong.
I said the IETF wants input. In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs. I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong. I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there. Coming to the IETF to have your solution rubberstamped invariably leads to disappointment. Go there to tell them about your problem. That works much better. But sending _me_ your input doesn't seem to make either of us happier.
On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 20:37, John Payne wrote:
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.
Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong.
I said the IETF wants input.
In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs.
You may not represent the IETF, but you are representative of the attitude of the IETF.
I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong.
There's something wrong with your attitude towards operators. There's a lot wrong with the IETF attitude towards operators, but you're here :)
I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there.
Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
On 2 feb 2011, at 21:18, John Payne wrote:
Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems.
You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken.
Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that. On 2 feb 2011, at 21:15, George Herbert wrote:
it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls.
Ok, I know I'm going to regret this, but: Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6? On 2 feb 2011, at 21:18, Owen DeLong wrote:
If you're connecting at a Starbuck's, and you care more than "hopefully somebody will tell me the right time within a minute", yes, it *is* essentially random.
While that is true, the people that are asking for the ability to advertise NTP servers in DHCP are not running the networks at Starbucks.
But whatever the IETF comes up with needs to work at Starbucks as well as enterprise networks, everything else you can think of and then some you can't. On 2 feb 2011, at 21:36, Lamar Owen wrote:
<put on op hat> What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required.
You can do that today. For instance, this is what I have in a test setup. (However, the ISC dhcpd can only do either v4 or v6, not both at the same time.) subnet6 2001:960:7bf:d::/64 { option dhcp6.name-servers 2001:1af8:2:5::2; option dhcp6.domain-search "bonjour.muada.nl"; range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; } Of course there are some subtleties such as the fact that some IPv6 systems don't support DHCPv6 so you also need stateless autoconfig if you want to be able to use those, and some (all?) routers automatically enable stateless autoconfig and don't tell hosts to use DHCP. But that can be fixed with two lines of config.
Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector
You also get to stop worrying about a few old ones.
It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets.
I did this for routing. 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). There are some good books on running IPv6, you know. :-)
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
IPv6 is what it is. There will be more tinkering but if you think there's enough
and yet it still isn't ready and standardly supported by OSes, routers, switches, software.... seems to me it's in the same mode it always has been.
Because IPv4-style DHCP often breaks because the DHCP server points to
Really? Never had that happen if I didn't configure it to happen... (and yes, I've done some pretty deep dhcp setups over the years, particular for WISP setups)
the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that.
On the NAT subject, I'll point out a recent change that I wasn't aware of, and a bit of history around it. It might help less people feel the "need" for NAT. At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48. Which means that a lot of the shops I've worked for over the years can get PI space where they couldn't before, and one of the heavy uses of NAT (renumbering sanity) disappears. (if you're singlehomed, 50% of /20..) For the history, v6 was originally pushed as -NO ONE- (who isn't an LIR or RIR) -EVER- gets PI space, you should use insert-magic-of-the-week-here. That's changed. We can now get PI space, and we can use it. So those of you who were thinking of using NAT with v6, how does that effect your plans? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Feb 2, 2011, at 3:09 PM, david raistrick wrote:
At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48.
One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first year) when it will probably be some time before we actually _need_ the addresses. The waivers a few years were a nice start but why does the cost need to double ever? It isn't like ARIN needs the money, they have more than they can spend. Once we are a "member" and have IPv4 space, the marginal cost to ARIN of assigning the equivalent in IPv6 space is pretty close to zero. Maybe some sort of NRC but doubling the annual cost just doesn't make sense. At least with IPv4 you can make the argument that the cost is artificially high to control usage but with IPv6 there are no more scarcity issues. I'd love to add IPv6 to the network but it just rubs me the wrong way to have to pay $2,220 a year to do so for something that essentially has no cost. I can't imagine having to justify it to a bean counter. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net -------------------------------------------------------------------------
On Wed, 2 Feb 2011, Chris Owen wrote:
On Feb 2, 2011, at 3:09 PM, david raistrick wrote:
At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48.
One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first
Ooof. I didn't get that far - and hadn't realized the waiver was expired. That's a pretty signficant barrier to entry. :( -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Feb 2, 2011, at 5:03 PM, david raistrick wrote:
On Wed, 2 Feb 2011, Chris Owen wrote:
On Feb 2, 2011, at 3:09 PM, david raistrick wrote:
At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48.
One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first
Ooof. I didn't get that far - and hadn't realized the waiver was expired.
That's a pretty signficant barrier to entry. :(
Um, I think you guys are mistaken... You're talking about ISP pricing, not end-user pricing. 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. Owen
One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first
Ooof. I didn't get that far - and hadn't realized the waiver was expired.
That's a pretty signficant barrier to entry. :(
Um, I think you guys are mistaken...
You're talking about ISP pricing, not end-user pricing.
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.
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. -Randy
On Feb 2, 2011, at 7:22 PM, Randy Carpenter wrote:
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.
I thought that was part of the "waiver" stuff that expires this year. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net -------------------------------------------------------------------------
From the main section on https://www.arin.net/fees/fee_schedule.html:
"... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees." It is not mentioned anywhere in the waiver stuff. -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message -----
On Feb 2, 2011, at 7:22 PM, Randy Carpenter wrote:
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.
I thought that was part of the "waiver" stuff that expires this year.
Chris
-- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net -------------------------------------------------------------------------
On Feb 2, 2011, at 8:38 PM, Randy Carpenter wrote:
From the main section on https://www.arin.net/fees/fee_schedule.html:
"... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees."
It is not mentioned anywhere in the waiver stuff.
Actually it is in the waiver stuff but I didn't see it at the top too. That's much more reasonable. Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net -------------------------------------------------------------------------
On 2/2/2011 8:38 PM, Randy Carpenter wrote:
From the main section on https://www.arin.net/fees/fee_schedule.html:
"... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees."
It is not mentioned anywhere in the waiver stuff.
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :) Jack
On Feb 3, 2011, at 9:00 AM, Jack Bates wrote:
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
Not sure I understand that one. /19 = 500 /29s /32 = 64,000 /48s Shouldn't the v6 blocks be a lot bigger? Chris -- ------------------------------------------------------------------------- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 - A stupidity tax Hubris Communications Inc www.hubris.net -------------------------------------------------------------------------
----- Original Message -----
On Feb 3, 2011, at 9:00 AM, Jack Bates wrote:
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
Not sure I understand that one.
/19 = 500 /29s
/32 = 64,000 /48s
Shouldn't the v6 blocks be a lot bigger?
Chris
Yes, they should be. Someone with a /19 would likely be looking at larger than a /32. Under proposal 121, it would be a /28, which would double the fee. I would imagine that the fee structure would have to change somehow, since /31 and /30, for example, won't even be an option. -Randy
On Feb 3, 2011, at 7:37 AM, Randy Carpenter wrote:
----- Original Message -----
On Feb 3, 2011, at 9:00 AM, Jack Bates wrote:
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
Not sure I understand that one.
/19 = 500 /29s
/32 = 64,000 /48s
Shouldn't the v6 blocks be a lot bigger?
Chris
Yes, they should be. Someone with a /19 would likely be looking at larger than a /32. Under proposal 121, it would be a /28, which would double the fee. I would imagine that the fee structure would have to change somehow, since /31 and /30, for example, won't even be an option.
-Randy
I fully expect that if proposal 121 is adopted (and I very much hope it will be), the board will make appropriate changes to the fee structure. It is also important to note that while 121 sets liberal maximum allocation sizes, it does not require providers to request or accept maximum allocations. A provider that qualifies for a /28 can request and get a /32 or even a /36 if they really want. So far, there has been good support for it, but if you are interested, please get on PPML and express your opinion. Owen
----- Original Message -----
On 2/2/2011 8:38 PM, Randy Carpenter wrote:
From the main section on https://www.arin.net/fees/fee_schedule.html:
"... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees."
It is not mentioned anywhere in the waiver stuff.
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
This is true, and is something that I hope ARIN addresses. Policy Proposal 121 urges the ARIN board to restructure the fees to more closely match the block sizes, should it be adopted. Hopefully both will happen. -Randy
On Feb 3, 2011, at 7:00 AM, Jack Bates wrote:
On 2/2/2011 8:38 PM, Randy Carpenter wrote:
From the main section on https://www.arin.net/fees/fee_schedule.html:
"... ISPs with both IPv4 resources and IPv6 resources pay the larger of the two fees."
It is not mentioned anywhere in the waiver stuff.
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
Jack
Actually, so far, most ISPs are finding themselves one rank lower. The exception is particularly small providers and there is a combination of suggestion (about fees) and policy (Proposal 121) effort underway to rectify that problem. Owen
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
Jack
Actually, so far, most ISPs are finding themselves one rank lower.
The exception is particularly small providers and there is a combination of suggestion (about fees) and policy (Proposal 121) effort underway to rectify that problem.
Owen
A specific example of the sizes of ISP I am working with: Most of them have between a /17 and a /20 of address space. If (hopefully when) Proposal 121 is adopted, all of the ones that are around a /17, should be getting a /28. Some of the ones that are /19 currently, would be getting a /28. While I wholeheartedly agree with Proposal 121, that represents 2 jumps in cost. These might represent some unusual situations, and might even fall under your definition of "particularly small." I hope that if Proposal 121 does pass, that the fees are restructured so that /36, /32, /28, /24, and /20 have different fees that line up with X-small, Small, Medium, Large, and X-large, respectively. -Randy
On Feb 3, 2011, at 8:39 AM, Randy Carpenter wrote:
The concept of v4 to v6 addressing scale doesn't match the pricing scale, though. Generally, I expect to see most ISPs find themselves 1 rank higher in the v6 model compared to v4, which effectively doubles your price anyways. :)
Jack
Actually, so far, most ISPs are finding themselves one rank lower.
The exception is particularly small providers and there is a combination of suggestion (about fees) and policy (Proposal 121) effort underway to rectify that problem.
Owen
A specific example of the sizes of ISP I am working with:
Most of them have between a /17 and a /20 of address space.
If (hopefully when) Proposal 121 is adopted, all of the ones that are around a /17, should be getting a /28. Some of the ones that are /19 currently, would be getting a /28. While I wholeheartedly agree with Proposal 121, that represents 2 jumps in cost. These might represent some unusual situations, and might even fall under your definition of "particularly small." I hope that if Proposal 121 does pass, that the fees are restructured so that /36, /32, /28, /24, and /20 have different fees that line up with X-small, Small, Medium, Large, and X-large, respectively.
-Randy
Randy, Without proposal 121, they would fall into the /32 category and would be in the same pricing category as they are today. I realize that if they get their maximum allowed allocation under proposal 121, they would be facing significant cost increases and I do sincerely hope that the board will address this issue promptly in the process of implementing 121 when it passes. However, my comment was targeted at the current situation pre-121. In the current situation, the only providers that pay more are those with less than a /20 who cannot get less than a /32 in IPv6. They are forced from the $1250 tier to the $2,250 pricing tier. Everyone else pays either the same or less under current policy. Owen
On Feb 2, 2011, at 5:22 PM, Randy Carpenter wrote:
One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first
Ooof. I didn't get that far - and hadn't realized the waiver was expired.
That's a pretty signficant barrier to entry. :(
Um, I think you guys are mistaken...
You're talking about ISP pricing, not end-user pricing.
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.
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.
-Randy
To the best of my knowledge, the board has no intention of changing that policy. I'd be surprised if that were the case. Owen
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
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
* 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 Weimer <fweimer@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
On Thu Feb 03, 2011 at 01:11:35PM +0000, Florian Weimer wrote:
Has RIPE charged a LIR for their independent resources yet? I don't think so. Therefore, comparisons with ARIN are a bit premature.
Yes - we got charged in our 2011 invoice. Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *
* Simon Lockhart:
On Thu Feb 03, 2011 at 01:11:35PM +0000, Florian Weimer wrote:
Has RIPE charged a LIR for their independent resources yet? I don't think so. Therefore, comparisons with ARIN are a bit premature.
Yes - we got charged in our 2011 invoice.
Very interesting. Are you sure it's not new allocations? I think we're still waiting for our provider-independent resources to be assigned to us. -- Florian Weimer <fweimer@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
On Feb 3, 2011, at 2:49 AM, 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).
http://wiki.answers.com/Q/What_is_geographic_monopoly Regards, -drc
On Wed, Feb 2, 2011 at 5:03 PM, david raistrick <drais@icantclick.org> wrote:
On Wed, 2 Feb 2011, Chris Owen wrote:
On Feb 2, 2011, at 3:09 PM, david raistrick wrote:
At least in ARIN territory, if you're multihomed, and you can show in-1-year use of 50% of a (v4) /24, you qualify for a PI v6 /48.
One of the things I find frustrating about this is the cost of the space. We're a very small shop and to add IPv6 addresses for testing now we're looking at paying another $2,200 a year ($1,700 in the first
Ooof. I didn't get that far - and hadn't realized the waiver was expired.
That's a pretty signficant barrier to entry. :(
Not sure of all your requirements, but you can use PA space. It is generally free if you are just looking for an entry into the v6 world. It may not fit for you, just saying ... I use PA in places where it works. Cameron
In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 21:18, John Payne wrote:
Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems.
You should have come to the IETF 10 or even 5 years ago. It's too late now, one day before the global pool of IPv4 addresses runs out. IPv6 is what it is. There will be more tinkering but if you think there's enough time to wait for your pet feature to be standardized and implemented widely, you're sorely mistaken.
I went to the IETF ~5 years and argued about the problems with RA's and the lack of things like a default route in DHCP. I had working group chairs tell me "You're an operator, you don't know what you're talking about, and clearly don't understand IPv6". After a few months of bashing my head against that abuse I gave up. This problem will now be solved by vendors, when operators put up cash. The solutions will be far uglier than if it was designed properly, and the IETF will fade even further into irrevelance.
Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that.
FUD, plain and simple. DHCP does not "often break", it's used by probably hundreds of millions of devices every day, mostly without problem. In fact, in my short time with IPv6 I've had several orders of magnitude more breakage with RA's than with DHCP. Actual operational experience. Try telling that to IETF folks though, and they are convinced you're just an idiot rather than trying to understand what happens when the rubber meets the road.
Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6?
I love this question, because it basically admits the protocol is broken. To make RA's even remotely palitable, you need "RA Guard" on the switches. This feature does not exist, but if we bring features like DHCP guard forward into the IPv6 world, it's the logical solution and solves the problem. However, to the IETF people who think this, they just don't understand how many networks are built and run. Let's split the problem space. Ther are folks who say run hotel or dorm networks and need to protect from bad, bad users. For them DHCP guard, RA guard, BotNet guard, and all sorts of other features need to be in the switches. However, there are a lot of corporate network users where there really is no rogue DHCP server. Perhaps they are even using 802.1x on end user ports, so there are no rogue users at all. However, they do need a robust networking configuration. I'll give the simple scenario I've done to myself twice. Went to a remote site. Replaced the router with a new router. Took the old router back to the office and plugged it in so I could upgrade the code. IPv6 stopped working instantly. IPv4 kept working just fine, forever. Why? Well, the router from the other site sends out RA's as soon as it is plugged in, and all the hosts believe it and sink traffic to it. On the IPv4 side it was a DHCP HELPER. Let me repeat that, it's the part the IETF folks always miss. IT WAS A DHCP HELPER. A box on the network goes to do a DHCP request. It goes to the actual router, and to this "rogue" remote office router. However, being not configured correctly the rogue router's DHCP helper points to a default route out a WAN interface that is down, and the packet is dropped. No response, the host gets a response from the real router and all is well. The mere act of plugging in a old router takes down IPv6, but leaves IPv4 working just fine. I'd say that's a LOT less robust. Rather than give me IPv6 DHCP that works like IPv4, and thus would be just as robust, the IVTF, the vendors making the decisions, want me to deploy RA guard, which ooops, isn't on any of the old switches so you'll have to replace all of them. Basically, as an operator, the vendors got together, developed a broken protocol, figured out a work-around that requires me to replace everything. Or in short, the vendors figured out how to make me replace everything. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Wed, Feb 2, 2011 at 16:13, Leo Bicknell <bicknell@ufp.org> wrote:
I love this question, because it basically admits the protocol is broken. To make RA's even remotely palitable, you need "RA Guard" on the switches. This feature does not exist, but if we bring features like DHCP guard forward into the IPv6 world, it's the logical solution and solves the problem.
RA Guard has been described in RFC 6105 (still draft, but standards track), so that particular problem should be taken care of once vendors start shipping code. It doesn't even require SeND- although it does accomodate it. ~Matt
On 02/02/2011 21:26, Matt Addison wrote:
RA Guard has been described in RFC 6105 (still draft, but standards track), so that particular problem should be taken care of once vendors start shipping code. It doesn't even require SeND- although it does accomodate it.
wonderful. In the interim, it is sheer lunacy to enable ipv6 on a large flat network if you can't synthesise ra guard with ipv6 packet filters. yes, there are some switches out there which do it already. They are very much in the minority. Nick
On Wed, Feb 2, 2011 at 1:13 PM, Leo Bicknell <bicknell@ufp.org> wrote:
In a message written on Wed, Feb 02, 2011 at 09:55:30PM +0100, Iljitsch van Beijnum wrote:
Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6?
I love this question, because it basically admits the protocol is broken. To make RA's even remotely palitable, you need "RA Guard" on the switches. This feature does not exist, but if we bring features like DHCP guard forward into the IPv6 world, it's the logical solution and solves the problem.
However, to the IETF people who think this, they just don't understand how many networks are built and run.
Let's split the problem space. Ther are folks who say run hotel or dorm networks and need to protect from bad, bad users. For them DHCP guard, RA guard, BotNet guard, and all sorts of other features need to be in the switches.
However, there are a lot of corporate network users where there really is no rogue DHCP server. Perhaps they are even using 802.1x on end user ports, so there are no rogue users at all. However, they do need a robust networking configuration.
I'll give the simple scenario I've done to myself twice. Went to a remote site. Replaced the router with a new router. Took the old router back to the office and plugged it in so I could upgrade the code.
IPv6 stopped working instantly. IPv4 kept working just fine, forever.
Why? Well, the router from the other site sends out RA's as soon as it is plugged in, and all the hosts believe it and sink traffic to it. On the IPv4 side it was a DHCP HELPER.
Let me repeat that, it's the part the IETF folks always miss.
IT WAS A DHCP HELPER.
A box on the network goes to do a DHCP request. It goes to the actual router, and to this "rogue" remote office router. However, being not configured correctly the rogue router's DHCP helper points to a default route out a WAN interface that is down, and the packet is dropped. No response, the host gets a response from the real router and all is well.
The mere act of plugging in a old router takes down IPv6, but leaves IPv4 working just fine. I'd say that's a LOT less robust. Rather than give me IPv6 DHCP that works like IPv4, and thus would be just as robust, the IVTF, the vendors making the decisions, want me to deploy RA guard, which ooops, isn't on any of the old switches so you'll have to replace all of them.
Basically, as an operator, the vendors got together, developed a broken protocol, figured out a work-around that requires me to replace everything. Or in short, the vendors figured out how to make me replace everything.
+1 Owen DeLong wrote, in response to the same query:
The lack of default router capabilities in DHCPv6 is a major disappointment. Yes, there are ways to work around this limitation in most environments, but, it is problematic to have this limitation.
+1 These seemingly minor features being absent caused 2 enterprises I consulted with in the medium-large size range (5,000-ish servers) to reject IPv6 for the time being. I could not figure out how to glue around the deficiency without fundamentally modifying how they manage and build and operate their server networks. They have several million end users of their services, probably approaching 10 million. -- -george william herbert george.herbert@gmail.com
Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
Because IPv4-style DHCP often breaks because the DHCP server points to the wrong router address and because NAT breaks end-to-end connectivity so severe workaround in applications become necessary. But you knew that.
IPv4 style DHCP occasionally (not often) breaks things because the DHCP server points to the wrong router address. On NAT, I actually agree with you.
On 2 feb 2011, at 21:15, George Herbert wrote:
it's hard to describe how frustrating this is without resorting to thrown fragile objects against hard walls.
Ok, I know I'm going to regret this, but:
Can you explain what exactly the problems with DHCPv6 are that you're running into that are inherent to DHCP and/or IPv6 host configuration and won't be fixed by bringing IPv4 ethernet switch features to IPv6?
The lack of default router capabilities in DHCPv6 is a major disappointment. Yes, there are ways to work around this limitation in most environments, but, it is problematic to have this limitation.
On 2 feb 2011, at 21:18, Owen DeLong wrote:
If you're connecting at a Starbuck's, and you care more than "hopefully somebody will tell me the right time within a minute", yes, it *is* essentially random.
While that is true, the people that are asking for the ability to advertise NTP servers in DHCP are not running the networks at Starbucks.
But whatever the IETF comes up with needs to work at Starbucks as well as enterprise networks, everything else you can think of and then some you can't.
Which is why the IETF should build an assortment of complete solutions that allow operators to choose the one that best meets their needs. It is absurd to limit the entire industry to a solution which cannot possibly be broken by misconfiguration by a barista. What we needed was RA/SLAAC with a way to specify DNS, NTP, and Next Server and DHCP with the ability to specify a default router. If we had these two complete solutions, operators would be able to choose whichever one fit best in each environment. Unfortunately, instead, what we got was two half-solutions that have to be combined to produce a suboptimal solution that sort of mostly works in most environments, mostly.
On 2 feb 2011, at 21:36, Lamar Owen wrote:
<put on op hat> What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required.
You can do that today. For instance, this is what I have in a test setup. (However, the ISC dhcpd can only do either v4 or v6, not both at the same time.)
Which means you can't do what he said, but...
subnet6 2001:960:7bf:d::/64 { option dhcp6.name-servers 2001:1af8:2:5::2; option dhcp6.domain-search "bonjour.muada.nl"; range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; }
Where's the default router? Right... No feature parity.
Of course there are some subtleties such as the fact that some IPv6 systems don't support DHCPv6 so you also need stateless autoconfig if you want to be able to use those, and some (all?) routers automatically enable stateless autoconfig and don't tell hosts to use DHCP. But that can be fixed with two lines of config.
Exactly.
Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector
You also get to stop worrying about a few old ones.
Not so much.
It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets.
I did this for routing. 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).
There are some good books on running IPv6, you know. :-)
I have to agree here... The conversion to dual-stack is not that hard in most situations. OWen
On Wednesday, February 02, 2011 03:55:30 pm Iljitsch van Beijnum wrote:
You can do that today. For instance, this is what I have in a test setup. (However, the ISC dhcpd can only do either v4 or v6, not both at the same time.)
First, thanks for taking the time to reply. That is appreciated. With the op hat on...... I want to dual-stack DHCP with complete feature parity, and it be done with one DHCP server. The only thing I should, speaking as an operator, have to do is add the IPv6 stanzas to the working v4 config, restart, and dualstack DHCP Just Works. If I have to hack the code myself to do it..... (and, while I might not, someone will, standards or no standards. "If it don't work, make it work.").
Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector
You also get to stop worrying about a few old ones.
As long as there's a dual stack, the vectors for v4 will work against the v4 portion of the stack. So, no, it ends up adding things to an already crowded plate.
I did this for routing. 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. If a book like Geoff Huston's excellent 'ISP Survival Guide' but for IPv6 (Hey, Geoff, is there an IPv6 version of your book?) were out there..... I know my 1999 edition of that book has seen plenty of use, mostly by people I loaned it out to when they asked me 'how does this thing called the Internet work?' A point-by-point "here's how you do in v6 that you're doing in v4" and "how to overlay your v6 subnets on RFC1918 NATted addresses without forklift upgrades in 12 easy steps" you might have an audience, as long as the first line of the book isn't "Everything you know is wrong." Even papers on how to rework your IPv4 network to more easily transition to dual-stack would be helpful (and those are probably out there; anybody got a cluepon page set up yet for those resources?)
There are some good books on running IPv6, you know. :-)
I know. My book budget got cut almost completely out last year, as well as the budget for more bookshelves and floor space, so I'll have to finance those by selling off old ones. Anybody want a CiscoPress ATM book or ten? :-)
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
In message <1397B616-F7F5-4212-B055-C0DFE1A99E3C@muada.com>, Iljitsch van Beijnum write s:
On 2 feb 2011, at 21:36, Lamar Owen wrote:
<put on op hat> What I want is to add an IPv6 subnet or subnets to my already tuned = DHCP server config, add IPv6 addresses to the addresses handed out (in = the same config clause as the IPv4 addresses are stored, preferably), = update the DHCP server software to IPv6-capability, restart the DHCP = server, and both IPv4 and IPv6 clients get what they need, through the = same already locked down channels, with no other upgrades required.
You can do that today. For instance, this is what I have in a test = setup. (However, the ISC dhcpd can only do either v4 or v6, not both at = the same time.)
Which is a limitation that we intend to address. It was more time sensitive to get a DHCPv6 server out there than a integrated DHCPv4/DHCPv6 server. No date has been set for this yet.
subnet6 2001:960:7bf:d::/64 { option dhcp6.name-servers 2001:1af8:2:5::2; option dhcp6.domain-search "bonjour.muada.nl"; range6 2001:960:7bf:d::1000 2001:960:7bf:d::1fff; }
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 2 Feb 2011 15:18:55 -0500 John Payne <john@sackheads.org> wrote:
On Feb 2, 2011, at 3:12 PM, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 20:37, John Payne wrote:
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.
Hey, I thought you wanted ops input... Here you are getting it, and look, here all you are doing is saying that its wrong.
I said the IETF wants input.
In case you hadn't noticed, I'm not the IETF. I don't represent them in any way. I'm not even a working group chair. I've gone to a bunch of meetings, spent way too much time on IETF mailinglists and co-wrote all of one RFCs.
You may not represent the IETF, but you are representative of the attitude of the IETF.
And I'm afraid you're representative of the "IPv4 thinking" attitude, that seems to believe that the past IPv4 ways are not just the only ways of solving a problem but are also naturally the best. They also seem assume that the way IPv6 is going to be used is exactly the same as IPv4, so the IPv4 methods will be perfect in all IPv6 applications. It's a bit of a shame that people who've gotten into networking in the last 10 to 15 years haven't studied or worked with anything more than IPv4. They've missed out on seeing a variety of different ways to solve the same types of problems and therefore been exposed to the various benefits and trade-offs of the different methods. With that sort of exposure, people may find out that there are other better ways to solve problems, but IPv4's limitations and constraints prevented them being possible.
I read some great writing advice once. It applies to much more than just writing. It goes like this: whenever a reader tells you that there's something wrong with your book, there is something wrong with your book. But if they tell you how to fix it, they're pretty much always wrong.
There's something wrong with your attitude towards operators. There's a lot wrong with the IETF attitude towards operators, but you're here :)
I'm not part of the DHC working group and I'm not a big DHCP user myself, so I don't claim to know the issues that exist with DHCPv6 in the operational community. But I'm sure there are some valid issues there. However, I'm equally sure that adding IPv4-DHCP-style router addresses to DHCPv6 is a big mistake that will create a lot of operational problems. Maybe not in the networks of the people that want this feature, but the problems will be there.
Having machines listen to any RA they receive is _today_ a cause of a lot of operational problems. Why do we need mommy-IETF telling us no for default routes in DHCP but letting RAs run wild? Why does the mere mention of NAT cause daddy-IETF to round up the troops and insist that everyone is wrong?
It's a bit of a shame that people who've gotten into networking in the last 10 to 15 years haven't studied or worked with anything more than IPv4. They've missed out on seeing a variety of different ways to solve the same types of problems and therefore been exposed to the various benefits and trade-offs of the different methods. With that sort of exposure, people may find out that there are other better ways to solve problems, but IPv4's limitations and constraints prevented them being possible.
Then there are some of us who *have* worked with other networking technologies (e.g. DECnet, XNS, Appletalk, X.25, etc) and *still* think that IPv6 is in many ways a horrible mess. IPv6 is at the same time both too much and not enough. It is "too much" because it is too different from IPv4, significantly slowing deployment and learning time. It is "not enough" because it really only solves one problem, namely address exhaustion - and not, for instance, the routing table explosion problem. (And don't get me started on the *claimed* advantages of IPv6, like "mandatory IPsec", "more efficient header processing" etc.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no
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:iljitsch@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.
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.
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.
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
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.
----- Original Message -----
From: "Michael Dillon" <wavetossed@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" AT&T 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
On Tuesday, February 15, 2011 11:57:46 pm Jay Ashworth wrote:
From: "Michael Dillon" <wavetossed@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" AT&T 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....
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.
On 2/15/2011 11:41 AM, Valdis.Kletnieks@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
In message <9271A508-9B5E-4919-AC14-487B8C8E8617@delong.com>, Owen DeLong write s:
On Feb 2, 2011, at 6:17 AM, Iljitsch van Beijnum wrote:
I didn't say they were necessarily good routers. =20 No, you said the router always knows better than the DHCP server. = This is an example of a common case where it does not. =20 If someone turns their box into a router they can also turn it into a = DHCP server. This is what happens with IPv4. The solution is to filter =
On 2 feb 2011, at 14:10, Owen DeLong wrote: =20 these packets from fake routers in the switches. So ask your switch = vendor for that feature in IPv6. =20 Turns out that this is A LOT less common and when it does happen, it's = easier to find and eliminate.
It really isn't. If the DHCP server on a subnet could override the = rogue routers RA messages by policy, then, it would actually make it = fairly trivial to address this issue. =20 And who overrides the rogue DHCPv6 messages? Or is it turtles all the = way down? =20 Turns out to be quite a bit easier to isolate and remove the rogue DHCP = server. Also turns out that there isn't a single-checkbox way to accidentally = create a DHCP server, unlike a rogue RA.
But there's so much wrong with DHCPv6 that trying to fix it is = pretty much useless, we need to abandon DHCP and start from scratch. = Good thing IPv6 works just fine without DHCPv6. =20 This is a clear example of the myopia in the IETF that has operators = so frustrated. =20 I can assure you that I'm quite alone within the IETF with that view. =20 Then you have had impressive success at blocking useful development for = a lone individual.
I'm not talking about the interaction between DHCPv6 and RAs here, = just about how bad DHCPv6 is on its own terms. For instance, there's no = client identifier or using MAC addresses to identify clients, this is = now done with a DUID. Unfortunately, administrators have no way of = knowing what DUID a given client is going to use so having a DHCPv6 = server set up with information tailored to a specific client is really = hard. There's also stateful and stateless DHCPv6, but it's the client = that has to choose between them, while the server knows whether it's = going to return stateful or stateless information. There's no prefix = length in DHCPv6, so this needs to be learned from RAs. (Although it can = be argued that because routers need to know this info anyway, having the = prefix length there doesn't buy you anything.) =20 I agree that there is much that needs to be improved in DHCPv6. The lack = of a default router, however, is the broken part that causes the most = difficulty in modern operations.
The problem with DHCP in general is that there is a continuous influx = of new options but they all need to be encoded into a binary format = inside a small packet. This info should be in an XML file on a HTTP = server instead, rather than be overloaded into the connectivity = bootstrapping. The problem with RA / DHCP is that RAs were built with = some vague notion of what DHCP would do some day and then when DHCPv6 = was developed half a decade later the evolving ideas didn't fit with the = shape of the hole left in RAs anymore but that problem wasn't addressed = at this time. Fixing that now (hopefully fixing it well, not doing = stupid things like making DHCPv6 an IPv4 DHCP clone with all the IPv4 = DHCP problems that we all suffer every day) means that we'll end up with = three types of systems: =20 We can agree to disagree about that. While it's true that there is a = large number of options and the DHCP packet needs to remain relatively = small, the reality is that no site uses all of them. They large number = of options represents a superset of the differing needs of various = sites.
XML on HTTP is too much overhead for things a system needs to know at = boot time to download its kernel.
Operationally, DHCPv4 is just fine and is meeting the needs today. = There's no reason we shouldn't have at least equivalent functionality in DHCPv6.
- no DHCPv6 - legacy DHCPv6 - new DHCPv6 =20 Good luck trying to come up with a combination of RA and DHCP settings = that make all three work well. Even without new DHCPv6, there's already = 12 ways to set up RAs and DHCP and only a few combinations produce = useful results.
Yes... It really would be better if both SLAAC and DHCPv6 provided = complete solutions and the operator could pick the single solution that = worked best for them.
Unfortunately, instead of looking at how things are used in the real = world, IETF pursued some sort of theoretical purity exercise and we have = two half-protocols that can't possibly provide a complete solution in = either one.
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.
DHCP fails because you can't get a default router out of it.
Owen
They didn't fail. They were designed to complement each other. It just that somewhere along the way people forgot that. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 02 Feb 2011 17:04:33 -0500, Mark Andrews <marka@isc.org> wrote:
They didn't fail. They were designed to complement each other. It just that somewhere along the way people forgot that.
No. They failed. In all respects. The political agendas within IPng were anti-NAT and anti-DHCP. So they designed a system without either completely ignoring the way the real world works. NAT certainly has it's place, but I won't go on any crusades for it. DHCP, however, is an integral part of most networks today. And that's been the case for many years (decades even.) RA is the IPv6 version of stupidity we've forgotten existed in IPv4 -- ICMP router discovery. The idiots that dreamed up RA/SLAAC completely ignored the necessities of modern networking... hostnames, domain names, DNS resolvers, netboot information, ... In the first days, SLAAC looked great because you had IPv4 DHCP filling in everything else, and an IPv4 stack providing support for all that. Now we're seeing DHCPv6 bolted on after the fact. And it's a peicemeal band-aid after band-aid, instead of the logical process of taking DHCPv4 and making all the address fields bigger. If you did, then in one *poof* DHCPv6 would be able to deliver IPv6 addresses for *EVERYTHING* DHCPv4 can. But you still have to have that awefull RA spewed into your network to tell systems to use DHCPv6. --Ricky
On Wednesday, February 02, 2011 05:04:33 pm Mark Andrews wrote:
They didn't fail. They were designed to complement each other. It just that somewhere along the way people forgot that.
My engineer brain looks at it this way: "The better is the enemy of the good." (Voltaire: "Le mieux est l'ennemi du bien."). I remember thinking back in my NetWare 2.x days that this thing called IP just needed the simplicity of IPX, with its native Layer 3 use of the MAC address..... boy, was I naive back then. Bridged ethernet across 56K leased lines with NetWare servers at the other end.... 3Com NetBuilders, and Vitalink's TransLAN III Bridges, I think. Been a long time. The TransLAN III device did the AUI interface to the 10Base5 LAN segments, IIRC.
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
Yeah, no-one needs to dynamically find out their local recursive name server or NTP server or network boot server. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
In message <alpine.LSU.2.00.1102021423590.5244@hermes-1.csi.cam.ac.uk>, Tony Fi nch writes:
On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote:
But there's so much wrong with DHCPv6 that trying to fix it is pretty much useless, we need to abandon DHCP and start from scratch. Good thing IPv6 works just fine without DHCPv6.
Yeah, no-one needs to dynamically find out their local recursive name server or NTP server or network boot server.
Tony.
DHCP was supposed to be use *with* RA's. Whether the network used managed address assignment or used SLAAC. The two were designed to complement each other. DNS and NTP server details were always supposed to be learned via DHCP. Similarly you were supposed to remember the prefix length before when kicking off the dhcp client with a managed network. Most of the problems seen are the result of not properly integrating the two parts. Somewhere along the way this was forgotten. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 02/02/2011 08:16, Iljitsch van Beijnum wrote:
Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.)
Regardless of the stated opinion of the IETF and its participants, there is a culture in the IETF of resistance to operational opinion. The DHCPv6 vs RA debacle is a direct consequence of this and a good example of both the problem and the serious consequences which ensue when one side doesn't listen. Nick
Regardless of the stated opinion of the IETF and its participants, there is a culture in the IETF of resistance to operational opinion. The DHCPv6 vs RA debacle is a direct consequence of this and a good example of both the problem and the serious consequences which ensue when one side doesn't listen.
some ietf ops participants have been fighting this for years, not always successfully. but recently, the ops within the ietf community have been banding together a bit more. the win rate is not a lot higher, but at least we can share the pain. :) your characterization of the dhcpv6 issue as a debacle is understated. it's flat out st00pid and insane, and loses ipv6 non-trivial market share. the religious fools have moved to the mentality that v4 scarcity will force ipv6 deployment and they don't have to compromise their ivory tower zealotry. they are bringing nats of all flavors on themselves. this would be fine if the rest of us did not also get the dren. randy
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 Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
On 2/2/2011 8:22 AM, Tony Finch wrote:
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.
CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs. Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments. Jack
On Feb 2, 2011, at 6:43 AM, Jack Bates wrote:
On 2/2/2011 8:22 AM, Tony Finch wrote:
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.
CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs.
Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments.
It's a lot easier to find and eliminate a rogue DHCP server than a rogue RA. Owen
On Wed, 2 Feb 2011 07:04:13 -0800 Owen DeLong <owen@delong.com> wrote:
On Feb 2, 2011, at 6:43 AM, Jack Bates wrote:
On 2/2/2011 8:22 AM, Tony Finch wrote:
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.
CounterCounterexample: rogue DHCPv6 servers from windows boxes or improperly connected CPEs.
Both DHCP(4 or 6) and RA require careful filtering to keep rogues from jacking things up. Though M$ has a nice deployment for authorizing DHCP4 servers in corporate environments.
It's a lot easier to find and eliminate a rogue DHCP server than a rogue RA.
How is that the case? The next hop for the default gateway that the rogue RA installs is the link local address, you look up the neighbor cache if the link local address doesn't have a MAC address in it, and then use layer 2 information to identify where it is attached. That's also the usual technique for finding and disabling a rogue DHCP server, so how is it any harder? Mark
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.
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
On 2/2/2011 2:16 AM, Iljitsch van Beijnum wrote:
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. Of course it does mean that people<gasp> have to learn something new when adopting IPv6.
Unfortunately, a PE router with large numbers of interfaces will have to duplicate the announcement periodically across every interface. The win isn't so clear. Jack
the problem is not whether RA is worth a damn, produces more erronious results, is harder to filter bad guys/gals, ... the problem is folk have *large* dhcp deployments. they look at going to ipv6 and say "wtf? i have to revamp my operation because of some religious nuts. rfc1918 is my friend. whew!" randy
On Feb 2, 2011, at 3:16 AM, Iljitsch van Beijnum wrote:
On 2 feb 2011, at 4:51, Dave Israel wrote:
They were features dreamed up by academics, theoreticians, and purists, and opposed by operators.
Contrary to popular belief, the IETF listens to operators and wants them to participate. Few do. For instance, I don't seem to remember your name from any IETF mailinglists. (I could be mistaken, though.)
From personal experience, the only reason die-hard IETF folk want operators to participate on IETF lists is so that they can tell them that they're wrong on IETF mailing lists as opposed to operator mailing lists.
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. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
Is anyone else reading this and the word "condescending" _not_ popping into their heads?
On Wed, 02 Feb 2011 14:30:23 EST, John Payne said:
On Feb 2, 2011, at 3:16 AM, 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. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
Is anyone else reading this and the word "condescending" _not_ popping into their heads?
The only other charitable conclusion I can draw is "Somebody hasn't spent time chasing down people with misconfigured laptops on the wireless who are squawking RA's for 2002:" There's a *big* operational difference between "all authorized and properly configured routers know who they are" and "all nodes that think they're routers (deluded though they may be) know who they are".
On 2/2/2011 2:42 PM, Valdis.Kletnieks@vt.edu wrote:
The only other charitable conclusion I can draw is "Somebody hasn't spent time chasing down people with misconfigured laptops on the wireless who are squawking RA's for 2002:"
There's a *big* operational difference between "all authorized and properly configured routers know who they are" and "all nodes that think they're routers (deluded though they may be) know who they are".
Amen to that, and add "all mischievous nodes that would /*love*/ to be your router / DNS / default gateway / etc" Jeff
In message <25915.1296675743@localhost>, Valdis.Kletnieks@vt.edu writes:
--==_Exmh_1296675743_5545P Content-Type: text/plain; charset=us-ascii
On Wed, 02 Feb 2011 14:30:23 EST, John Payne said:
On Feb 2, 2011, at 3:16 AM, 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. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
Is anyone else reading this and the word "condescending" _not_ popping into their heads?
The only other charitable conclusion I can draw is "Somebody hasn't spent tim e chasing down people with misconfigured laptops on the wireless who are squawk ing RA's for 2002:"
There's a *big* operational difference between "all authorized and properly c onfigured routers know who they are" and "all nodes that think they're routers (deluded though they may be) know who they are".
Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 02 Feb 2011 17:18:25 -0500, Mark Andrews <marka@isc.org> wrote:
Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now.
Get back to me when you control every network device in the world. That may work for you. In your network. On devices you control. However, the brokenness is still there. --Ricky
In message <op.vqassatytfhldh@rbeam.xactional.com>, "Ricky Beam" writes:
On Wed, 02 Feb 2011 17:18:25 -0500, Mark Andrews <marka@isc.org> wrote:
Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now.
Get back to me when you control every network device in the world.
That may work for you. In your network. On devices you control. However, the brokenness is still there.
And rogue DHCP servers also exist. The reason you see lots of rouge 2002: prefixes announcements is that ISP's havn't delivered IPv6 so people have routed around them and turned on 6to4 on their machines. The problem will mostly go away once consumer ISP's get off their butts and actually deliver IPv6 when their customer asked for it (I've been asking this of my ISP for the last 7 or so years and I suspect I was not alone). This is industry self inflicted pain. As for hosts swithing over to the new prefix immediately I suspect a lot of that will go away as the host OS's mature. Just selecting the router by matching it prefix announcements to the source address will keep existing sessions going. It also works better with bcp38 filters. Add rules which depreference 2002: source addresses and you won't notice these RA's anymore (this part already exists). In Leo's case the source address selection part wouldn't have helped but Leo's case is the router wouldn't have had a 2002 address but this senario is also rarer. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Feb 2, 2011, at 2:18 PM, Mark Andrews wrote:
In message <25915.1296675743@localhost>, Valdis.Kletnieks@vt.edu writes:
--==_Exmh_1296675743_5545P Content-Type: text/plain; charset=us-ascii
On Wed, 02 Feb 2011 14:30:23 EST, John Payne said:
On Feb 2, 2011, at 3:16 AM, 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. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
Is anyone else reading this and the word "condescending" _not_ popping into their heads?
The only other charitable conclusion I can draw is "Somebody hasn't spent tim e chasing down people with misconfigured laptops on the wireless who are squawk ing RA's for 2002:"
There's a *big* operational difference between "all authorized and properly c onfigured routers know who they are" and "all nodes that think they're routers (deluded though they may be) know who they are".
Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now.
That works when you're one technician on one laptop. Now, scale that solution to 10,000 $END_USERS on 12,000 laptops running at least 4 versions of at least 3 different operating systems (12 combinations minimum). Really? Owen
On Thu, 03 Feb 2011 09:18:25 +1100, Mark Andrews said:
Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now.
You're welcome to stop by and fix 30,000+ systems here, most of which we do *not* have administrative control over because they're personal laptops and the like. For most of these users, if it doesn't do the filtering correctly out of the box when they pick it at Best Buy or Walmart or whatever, it isn't going to get reconfigured. (We do provide a free "configure your box for our network" CD that does all this stuff and installs a site-licensed AV and all that, but not everybody actually uses it, and there's no really good way to mandate it - and anyhow, that's a purely local fix for a problem that's more than local). (We'll overlook the fun and games that start when you have a laptop that travels between a site where 2002:: is verboten, and another where 2002:: is the way it has to be done... Doesn't happen much.. *yet*. Good luck explaining *that* to Joe Sixpack)
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
(We'll overlook the fun and games that start when you have a laptop that travels between a site where 2002:: is verboten, and another where 2002:: is the way it has to be done... Doesn't happen much.. *yet*. Good luck explaining *that* to Joe Sixpack)
With all due respect to the people who had to get it done... And so *this* you call "engineering"? Was TCP/IP this bad back in 1983, folks? Cheers, -- jra
On Feb 3, 2011, at 11:11 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
(We'll overlook the fun and games that start when you have a laptop that travels between a site where 2002:: is verboten, and another where 2002:: is the way it has to be done... Doesn't happen much.. *yet*. Good luck explaining *that* to Joe Sixpack)
With all due respect to the people who had to get it done...
And so *this* you call "engineering"?
Was TCP/IP this bad back in 1983, folks?
Cheers, -- jra
In different ways, yes, it was. Owen
<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.
In article <F05D77A9631CAE4097F7B69095F1B06F039104@EX02.drtel.lan>, Brian Johnson <bjohnson@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
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 raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
In article <alpine.BSF.2.00.1102041723070.54349@murf.icantclick.org>, david raistrick <drais@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
On Feb 5, 2011, at 1:54 AM, Roland Perry wrote:
In article <alpine.BSF.2.00.1102041723070.54349@murf.icantclick.org>, david raistrick <drais@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)
In article <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com>, Owen DeLong <owen@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
On Feb 6, 2011, at 9:45 AM, Roland Perry wrote:
In article <85D304BA-6C4E-4B86-9717-2ADB542B8606@delong.com>, Owen DeLong <owen@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.
It has worked for me so far in several countries. No, it's not an FCC thing, it's called "Truth in advertising" and/or Fraud. 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.
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.
As I said, I don't use a tether device (the dongle would qualify as a tether device in my meaning).
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.
While this is true, for whatever unfortunate reasons, those users seem to expect and accept a certain level of brokenness in their internet access. When I looked into the mobile contracts I have (SPRINT 4G/EVDO service for my phone and AT&T 3G service on my iPad), it was pretty clear that they promised to provide whatever they felt like under whatever circumstances they chose and I was supposed to pay whether it works or not. Unfortunately, lacking viable alternatives, we live with that, but, at least in their case, the contract specifies that I accept brokenness as built in to their service models. Owen
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
In message <CLGJgQW4YHTNFAWL@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: marka@isc.org
In article <20110204225150.6FAC49B2854@drugs.dv.isc.org>, Mark Andrews <marka@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
In message <xq1VY4E3BSTNFAjp@perry.co.uk>, Roland Perry writes:
In article <20110204225150.6FAC49B2854@drugs.dv.isc.org>, Mark Andrews <marka@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: marka@isc.org
In article <20110205131510.BE13E9B5167@drugs.dv.isc.org>, Mark Andrews <marka@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
On Feb 6, 2011, at 9:49 AM, Roland Perry wrote:
In article <20110205131510.BE13E9B5167@drugs.dv.isc.org>, Mark Andrews <marka@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
----- Original Message -----
From: "Owen DeLong" <owen@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
On Feb 6, 2011, at 10:34 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Owen DeLong" <owen@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
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 <henry@aegis00.com> (800) 234-4700
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
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
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
Once upon a time, Henry Yen <henry@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 <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
In message <23119638.5335.1297017284299.JavaMail.root@benjamin.baylink.com>, Ja y Ashworth writes:
----- Original Message -----
From: "Owen DeLong" <owen@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: marka@isc.org
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
In message <4D4F27E4.6080604@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: marka@isc.org
---- Original Message -----
From: "Brian Johnson" <bjohnson@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
On Feb 4, 2011, at 6:23 PM, Jay Ashworth wrote:
---- Original Message -----
From: "Brian Johnson" <bjohnson@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
In article <F432E474-9725-4159-870A-D5432FE6EE4D@delong.com>, Owen DeLong <owen@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
In message <eqDe49GvPSTNFAnW@perry.co.uk>, Roland Perry writes:
In article <F432E474-9725-4159-870A-D5432FE6EE4D@delong.com>, Owen DeLong <owen@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 AAAA records. The outbound side should just work. Next you add AAAA 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: marka@isc.org
In message <32825.1296757039@localhost>, Valdis.Kletnieks@vt.edu writes:
--==_Exmh_1296757039_6170P Content-Type: text/plain; charset=us-ascii
On Thu, 03 Feb 2011 09:18:25 +1100, Mark Andrews said:
Or you just filter them out in the laptop. With the proper tools you just ignore and RA's containing 2002:. Done that for years now.
You're welcome to stop by and fix 30,000+ systems here, most of which we do *not* have administrative control over because they're personal laptops and t he like. For most of these users, if it doesn't do the filtering correctly out of the box when they pick it at Best Buy or Walmart or whatever, it isn't going to get reconfigured. (We do provide a free "configure your box for our network" CD that does all this stuff and installs a site-licensed AV and all that, but no t everybody actually uses it, and there's no really good way to mandate it - an d anyhow, that's a purely local fix for a problem that's more than local).
(We'll overlook the fun and games that start when you have a laptop that travels between a site where 2002:: is verboten, and another where 2002:: is the way it has to be done... Doesn't happen much.. *yet*. Good luck explaini ng *that* to Joe Sixpack)
Joe sixpack is quite capable of learning this stuff. That said modern OS also come with connection profiles which make this even easier and will reduce the incidents of rougue RA as DHCP as connection sharing gets tied to the profile. Additionally connection sharing will shift for using 6to4 to doing prefix delegation. OS vendors that support connection sharing should also look at the IPv6 CPE draft as lots of that is applicable. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wednesday, February 02, 2011 03:16:59 am Iljitsch van Beijnum wrote:
A clear win. Of course it does mean that people <gasp> have to learn something new when adopting IPv6.
Ever hear of intellectual inertia? The more that has to be learned to go a new path, the less likely that path will be chosen if another path still works, or can be made work with incremental changes. There's already too much new to learn, and not as many available hours or people to learn it. <put on op hat> What I want is to add an IPv6 subnet or subnets to my already tuned DHCP server config, add IPv6 addresses to the addresses handed out (in the same config clause as the IPv4 addresses are stored, preferably), update the DHCP server software to IPv6-capability, restart the DHCP server, and both IPv4 and IPv6 clients get what they need, through the same already locked down channels, with no other upgrades required. Takes what, thirty minutes per DHCP server if you're slow? Instead, I'll have to completely relearn how dynamic allocation works, learn about and protect against a new attack vector, learn about and deploy new hardware and software more than likely, and in general pull my hair out debugging new code and new platforms.... and so I'll be inclined to keep what works and bandaid it until it cannot be bandaided any more. Sorry, but those are the operational facts of life. <take off op hat> IPv6's uptake has been slow because it is too different, IMO, and thus intellectual inertia (in the complete Newtonian physics sense of the word) kicks in. IPv4 is a huge mass moving at a large velocity, and the delta force vector to adjust course is too great for many to swallow. It doesn't seem that different until you add all those pesky little details up. Try that exercise one day, and add up *all* the differences that operators have to know and implement to go IPv6, and balance that against smaller staffs and smaller budgets.
On Tue, Feb 1, 2011 at 6:24 PM, Chris Adams <cmadams@hiwaay.net> wrote:
Once upon a time, Owen DeLong <owen@delong.com> said:
On Feb 1, 2011, at 3:41 PM, Karl Auer wrote:
Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing.
Which is a bug, not a feature.
That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. 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.
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 raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
Sounds like PI space is a solution for those 5000 desktops. Frank -----Original Message----- From: david raistrick [mailto:drais@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 raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
----- Original Message -----
From: "david raistrick" <drais@icantclick.org>
On Tue, 1 Feb 2011, Dave Israel wrote:
responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them.
Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback.
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. Cheers, -- jr 'dirty little secret' a
On Wed, 2 Feb 2011, 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.
Heh. My personal hope, anyway, is that it will motivate certain software engineers (and companies) who decide that DNS isn't worthwhile to support (for x y z or no reason) will never be able to remember the new addressing schemes, and find themselves having to use DNS...and thereby adding support to their code. In which case, bring it on! :) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On 02/02/2011 06:31 PM, Jay Ashworth wrote:
----- Original Message -----
From: "david raistrick"<drais@icantclick.org> On Tue, 1 Feb 2011, Dave Israel wrote:
responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. Not to mention that when you take tools -away- from people that solve an existing problem, you'll get a lot of pushback. 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 know, DNS is awesome, but DNS also breaks (SysAdmin mantra: "It's a DNS problem", because if something is behaving in an unusual fashion, it's usually DNS that's at fault). I guess I'll routinely be storing a copy of the zone file in my DropBox or something as a precaution so I can access it from my phone. Paul
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
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
On 1 feb 2011, at 21:03, Dave Israel wrote:
People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted.
The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a < 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages. So I'm all in favor of the IETF blocking stupidity whenever possible.
On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote:
On 1 feb 2011, at 21:03, Dave Israel wrote:
People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a< 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages.
So I'm all in favor of the IETF blocking stupidity whenever possible.
I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that "customers cannot reach me because of my configuration choice" is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem. -Dave
On Tue, 1 Feb 2011, Dave Israel wrote:
I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that "customers cannot reach me because of my configuration choice" is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem.
DHCPv6 can have a very valid and useful place in the overall scheme of things, in terms of managing address assignments. I've been somewhat disappointed that it's taken this long to see the light of day. jms
In message <4D4870B8.4010809@otd.com>, Dave Israel writes:
On 1 feb 2011, at 21:03, Dave Israel wrote:
People want to engineer their networks they way they want to. Let them. If
On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote: their way is stupid, then they'll have the stupidly engineered network they wa nted.
The problem is that their stupidity impacts ME. If I want to talk to Microsof t from behind a< 1500 byte MTU link: too bad, not going to happen. They stupid ly send packets with DF=1 but filter incoming packet too big messages.
So I'm all in favor of the IETF blocking stupidity whenever possible.
I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that "customers cannot reach me because of my configuration choice" is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem.
-Dave
It just doesn't work with Microsoft, ATT, AOL, .... They make up their own rules and you have to figure them out. Microsoft set TC on DNS replies but doesn't have DNS open on TCP. Then there is the anti-spam measures which break RFC compliance. Or all the people that have GLB's that don't give correct answers to AAAA queries. How had is it to return the SOA record of the delegated zone rather than the parent zone. Some GLB vendors documentation gets this wrong. The Alexa top 1000000 has a 1.4% failure rate on AAAA queries (SERVFAIL, TIMEOUT to the client when NOERROR or NXDOMAIN is returned for A). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote:
What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses?
If you like NAT IPv4 is the place to be, it'll only get more and more.
It's argument like this that has lead to this moment. Instead of discussing "how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow" we tell people "if you don't like it, use v4" Guess what? We're still using v4. ..david -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On 02/01/2011 10:08 AM, david raistrick wrote:
On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote:
What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses?
If you like NAT IPv4 is the place to be, it'll only get more and more.
It's argument like this that has lead to this moment. Instead of discussing "how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow" we tell people "if you don't like it, use v4"
Guess what? We're still using v4.
..david
We're still using v4 because we can, because there has been no compelling business case to justify spending time on something that isn't necessary just right now, especially given the not insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. We can all sit here and say "Hey we're running out of addresses, we must switch" but until we've run out you're not going to convince the large majority of operators, who lets face it are traditionally lazy^W^W cautious people , to do anything. Paul
On Tue, Feb 01, 2011 at 10:27:45AM -1000, Paul Graydon wrote:
insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either.
Paul, You're speaking for yourself here, as some of us have hosts with no A record. If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point. It's not as if we haven't had 15 years to get it together... Cheers, --msa
On Tue, Feb 1, 2011 at 3:32 PM, Majdi S. Abbas <msa@latt.net> wrote:
If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point.
+1 Regards, Martin
On Tue, Feb 01, 2011 at 10:27:45AM -1000, Paul Graydon wrote:
insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either. Paul,
You're speaking for yourself here, as some of us have hosts with no A record.
If your business requires connectivity, you're not going to have a choice, so you might as well get with the program. It's less about making a business case for v6, and more about risk management at this point.
It's not as if we haven't had 15 years to get it together...
Cheers,
--msa I should emphasise I'm a sysadmin rather than a service provider, and I'm mostly speaking generically based on conversations with a number of sysadmins. I've been trying to get my service provider to sort out IPv6 for a while now (they tell me their infrastructure is ready, but they're being lazy about getting blocks sorted out) and already done as much preparation as I can with my infrastructure to ensure its ready for it. That said there are no services we use that are IPv6 only, nor are there
On 02/01/2011 10:32 AM, Majdi S. Abbas wrote: likely to be for a while that I can tell as none of our service partners are talking about it, and nor are we getting reports of anyone unable to access our services due to lack of IPv6 on the front end. I know how ugly that sounds, I really do, but that's the way most people will see it. You have to provide incentive to make a change, and "It's better" rarely is enough. "People won't be able to access our site" sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). People bury their heads in the sand and will continue to pretend there is nothing wrong until they're /forced/ to change. As much as it was a hideous and inaccurate article, that Fox news story that was posted on list the other day came up was great for fighting for change. The grossly inaccurate end-of-the-world text provides a good hook for getting the lumbering beast moving in the right direction. The White House's push for IPv6 amongst federal agencies is currently my best guess at what will probably see the first thing to transition to it from my perspective at work, though I sincerely hope we'll be on IPv6 long before that happens. As for when we'll switch internally? No idea.. all machines have IPv6 so some local traffic probably uses it, but most are still based on IPv4 and until I have time / money to make some other infrastructure changes will remain that way (our office environment equipment can't handle IPv6, unlike our production environment) I'm sure there are some cases with IPv6, yourself as an example, and I know an ISP I worked for in the UK had a customer several years ago who had a critical need for it, but that's still in the minority. In every case as soon as there is a business reason for it and its compelling enough people will take the time to make the transition. Paul
"People won't be able to access our site" sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.).
Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change. Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented. Oh, and when I said to pick your RIR, I meant the RIR of users who access your content. Lee
On Feb 1, 2011, at 3:54 PM, Lee Howard wrote:
"People won't be able to access our site" sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.).
Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change.
Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented.
Oh, and when I said to pick your RIR, I meant the RIR of users who access your content.
Lee
I think there is a key problem with Geoff's graph. I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration. It does not appear to me that this probability is accounted for in the plots. Owen (Including Geoff because it's not fair to criticize his work behind his back)
On 02/01/2011 04:11 PM, Owen DeLong wrote:
On Feb 1, 2011, at 3:54 PM, Lee Howard wrote:
"People won't be able to access our site" sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.). Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change.
Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented.
Oh, and when I said to pick your RIR, I meant the RIR of users who access your content.
Lee
I think there is a key problem with Geoff's graph.
I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration.
It does not appear to me that this probability is accounted for in the plots.
Owen
(Including Geoff because it's not fair to criticize his work behind his back)
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation. Paul
On 02/01/2011 08:27 PM, Paul Graydon wrote:
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation.
I've heard that it's already started at ARIN. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 x203 Fax: 312-602-2688 Cell: 312-320-5867
On Feb 1, 2011, at 9:39 PM, Kevin Stange wrote:
On 02/01/2011 08:27 PM, Paul Graydon wrote:
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation.
I've heard that it's already started at ARIN.
We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush". FYI, /John John Curran President and CEO ARIN
On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said:
We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush".
Any trending on the rate of requests for IPv6 prefixes?
On Tue, Feb 1, 2011 at 7:46 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said:
We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush".
Any trending on the rate of requests for IPv6 prefixes?
More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates. Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag. -- -george william herbert george.herbert@gmail.com
On Feb 1, 2011, at 11:05 PM, George Herbert wrote:
More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates.
Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag.
I don't believe we've had an IPv6 "additional" request yet (but I look forward to it happening at some point :-). I will check and get back to the list with the definitive answer. /John John Curran President and CEO ARIN
On 2/1/2011 10:19 PM, John Curran wrote:
I don't believe we've had an IPv6 "additional" request yet (but I look forward to it happening at some point:-). I will check and get back to the list with the definitive answer.
I believe that the changing of IPv6 policy leads to "redo's", and I expect to see expansions again if current proposals are accepted. I don't believe enough eyeballs have been assigned address space yet with current policy to draw necessity yet. Further expansions would likely reduce that necessity even further. Jack
On Feb 1, 2011, at 11:19 PM, John Curran wrote:
On Feb 1, 2011, at 11:05 PM, George Herbert wrote:
More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates.
Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag.
I don't believe we've had an IPv6 "additional" request yet (but I look forward to it happening at some point :-). I will check and get back to the list with the definitive answer.
It turns out we've had a handful of ISPs come back for additional IPv6 blocks but it was the result of an better understanding of their evolving address allocation requirements pre-deployment. FYI, /John John Curran President and CEO ARIN
Not necessarily. There was a proposal passed at ARIN and I have a similar one proposed for APNIC where you can request a second allocation should you need it for a variety of justification. For example: disparate non-connected networks under a different AS's. This is the one that is bothering me at the moment. ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - On 2/02/11 3:05 PM, "George Herbert" <george.herbert@gmail.com> wrote:
On Tue, Feb 1, 2011 at 7:46 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said:
We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush".
Any trending on the rate of requests for IPv6 prefixes?
More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates.
Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag.
-- -george william herbert george.herbert@gmail.com
On Tue, Feb 1, 2011 at 11:32 PM, Skeeve Stevens <Skeeve@eintellego.net> wrote:
Not necessarily.
There was a proposal passed at ARIN and I have a similar one proposed for
<http://lists.arin.net/pipermail/arin-ppml/2010-December/019040.html> (I think you mean, or the one dave farmer's been working on for a time now) -chris
On Feb 1, 2011, at 8:05 PM, George Herbert wrote:
On Tue, Feb 1, 2011 at 7:46 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said:
We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush".
Any trending on the rate of requests for IPv6 prefixes?
More interesting would be re-requests - organizations exhausting an initial allocation and requiring more. People asking for the first one just indicates initial adoption rates.
Other than experimental blocks, I am generally under the impression that IPv6 allocations are designed to avoid that being necessary for an extended period of time. If that is not true, then that's a flag.
There are definitely policy changes needed in order to make this true. I doubt that there are many network operators that have deployed enough IPv6 to be up against that wall yet. I know of only one. ARIN Policy Proposal 121 is intended to improve that situation significantly and also reduce the probability for human-factors related outages in the future in IPv6. Owen
On Feb 1, 2011, at 10:46 PM, Valdis.Kletnieks@vt.edu wrote:
On Wed, 02 Feb 2011 03:09:50 GMT, John Curran said:
We had a small ramp up in December (about 25% increase) but that is within reasonable variation. Today was a little different, though, with 4 times the normal request rate... that would be a "rush".
Any trending on the rate of requests for IPv6 prefixes?
A quick review shows no significant change in IPv6 request rate January through today, although I would point out that the second of half of 2010 had a fairly significant ramp up in IPv6 requests (both assignments and allocations). You can view all the 2010 charts are online here: https://www.arin.net/knowledge/statistics/index.html. FYI, /John John Curran President and CEO ARIN
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation.
This question probably calls for another picture. Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period. http://www.potaroo.net/tools/ipv4/daily-allocs.jpg Geoff
On Wed, Feb 2, 2011 at 1:29 AM, Geoff Huston <gih@apnic.net> wrote:
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation.
This question probably calls for another picture.
Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period.
http://www.potaroo.net/tools/ipv4/daily-allocs.jpg
Geoff
Oh master of the awesome graphingness...can you do a corresponding slide for v6 allocation rates, so we can see if the runout is helping inspire additional interest for networks in perhaps investigating v6 more seriously? Thanks! Matt
On 2/2/11 10:29 AM, Geoff Huston wrote:
Are there any expectations of a Gold Rush for the remaining addresses? I would expect to see at least see some kind of escalation.
This question probably calls for another picture.
Here is a plot of 2009 and 2010 in terms of the average number of IPv4 addresses allocated on a daily basis, across all 5 RIRs. I've used a smoothing function across the allocation data in order to clearly show the trend pattern over the two year period.
http://www.potaroo.net/tools/ipv4/daily-allocs.jpg
Geoff
We published a similar graph on RIPE Labs last friday. It shows the 6 months rolling average allocation rate for each RIR (in units of /8s per month). APNIC's allocation rate has been on a steady rise since 2008. After coming down in 2009/2010, the average rates in ARIN and RIPE have gone up again recently. Could be the first signs of a gold rush, or just a coincidence. https://labs.ripe.net/Members/wilhelm/images/IPv4RatesPerRIR.png -- Rene
On 02/02/2011, at 1:11 PM, Owen DeLong wrote:
On Feb 1, 2011, at 3:54 PM, Lee Howard wrote:
"People won't be able to access our site" sure helps but being unable to put a date on it still reduces incentive (especially when Management get involved, and especially if there is a financial outlay involving firewalls etc.).
Geoff generously provided a probabilistic sense for RIR runout: http://www.potaroo.net/tools/ipv4/rir.jpg Pick your RIR and plot its runout date. If it's ARIN, then the first ISP is out of IPv4 addresses at most three months later (since ARIN now allocates for three months' need). Of course, if demand increases, these dates might change.
Will users be unable to reach your content on $RIR_runout_date + 3? They might have to get there through large-scale NAT. That might bother management if you rely on IP geo-location, or need to initiate connections downstream, or rate limit per IP address, or have anti-DOS techniques measuring hits per source IP address, or have employees VPN in, or need to report intrusions, or any of the many problems widely documented.
Oh, and when I said to pick your RIR, I meant the RIR of users who access your content.
Lee
I think there is a key problem with Geoff's graph.
I think it fails to take into account the transitive probability of requests among the largest 3 regions. I agree that APNIC will probably run just about exactly as he predicts. I think, however, that the runout at APNIC will create a higher demand in ARIN and RIPE. Once that happens, their runout dates will get moved up much closer to the runout date of APNIC. As soon as the second of the three runs out, the remaining one will get another burst of acceleration.
It does not appear to me that this probability is accounted for in the plots.
Owen
(Including Geoff because it's not fair to criticize his work behind his back)
Yes - a certain (X) percent of demand will shift out from a region once that region's stocks are depleted. What value X realistically takes is not something I can factor into these models, nor can I predict where this unmet demand may surface in the remaining regions. The future of IPv4 contains many uncertainties. Geoff
On Tue, 01 Feb 2011 10:27:45 -1000, Paul Graydon said:
We're still using v4 because we can, because there has been no compelling business case to justify spending time on something that isn't necessary just right now, especially given the not insignificant changes between v4 and v6. There is nothing on line that isn't accessible over IPv4 so there has been no critical app outside the infrastructure to spur such changes yet either.
And if you're not working on deploying IPv6 now, will you be able to survive the delay when something critical *does* come online and you need 18 months or whatever to deploy? Heck - we started deploying in Feb 1997 or so, and as I write this, MRTG is reporting that about 5% of our off-campus traffic is via IPv6 - probably due to the fact that we hit Google and Youtube that way. But we *still* have gear and software that doesn't play nice (though almost all of that is our own internal headaches and not very visible to end users - their connectivity works).
On Feb 1, 2011, at 12:08 PM, david raistrick wrote:
On Tue, 1 Feb 2011, Iljitsch van Beijnum wrote:
What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses?
If you like NAT IPv4 is the place to be, it'll only get more and more.
It's argument like this that has lead to this moment. Instead of discussing "how can the next generation addressing scheme support the needs of Internet consumers today and tomorrow" we tell people "if you don't like it, use v4"
Guess what? We're still using v4.
..david
Enjoy that. Let's see how that goes in 5-7 years. If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be. Owen
________________________________ From: Owen DeLong <owen@delong.com> David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your >IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and >move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be.
Lack of NAT may or may not continue to be a barrier to IPv6 adoption. However, it certainly *has* been a barrier to IPv6 adoption - I have had customers tell me that explicitly, and I have no reason to doubt them.
On Feb 1, 2011, at 2:43 PM, David Barak wrote:
________________________________
From: Owen DeLong <owen@delong.com>
David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your >IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and >move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be.
Lack of NAT may or may not continue to be a barrier to IPv6 adoption. However, it certainly *has* been a barrier to IPv6 adoption - I have had customers tell me that explicitly, and I have no reason to doubt them.
I'm sure there are a few isolated places where IPv6 might have been adopted if it hadn't been for the fact that nobody has educated them on the alternatives. However, I'm not convinced there are very many of them. Most of the people I have had more detailed conversations with go something like this: X: We con't implement IPv6 because there's no NAT and we depend on NAT. O: Why do you depend on NAT? All it does is conserve addresses? X: We use it for address obfuscation and security. We have to meet PCI-DSS and other audit criteria. O: Well, the latest PCI-DSS doesn't require NAT. Additionally, you can get better address obfuscation with privacy addresses. All the security in NAT comes from stateful inspection. You can still do that in IPv6, you just don't rewrite the address in the packet. X: You've got an answer for everything, don't you? O: Well, I've been doing IPv6 for a few years now. It works pretty well for me and I'm really glad I don't have to deal with the problems caused by NAT. X: Well, OK, but, even if we ignore NAT, we're still not ready to do IPv6. Then we discuss their real issues stopping them from going to IPv6. So... I think there are a lot more people using NAT as an excuse than there are people that would actually implement IPv6 if we just gave them NAT. In any case, I think as they find their NATv4 environment becoming an island disconnected from the internet, they'll probably reconsider that decision. I'm OK with waiting until that time for those people to connect to IPv6. Owen
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be.
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view. Cheers, -- jra
On Wed, Feb 2, 2011 at 22:34, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
If you're determined to destroy IPv6 by bringing the problems of NAT forward with you, then, I'm fine with you remaining in your IPv4 island. I'm willing to bet that most organizations will embrace an internet unencumbered by the brokenness that is NAT and move forward. I do not think that lack of NAT has been a significant barrier to IPv6 adoption, nor do I think it will be.
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view.
Cheers, -- jra
Quite simply, its called Tragedy of the Commons. Everyone else has to work harder to provide you services if you are using something which breaks end to end connectivity, which costs everyone else money. The protocol designers are making a stand against this for the good of the "commons". -Blake
----- Original Message -----
From: "Blake Dunlap" <ikiris@gmail.com>
On Wed, Feb 2, 2011 at 22:34, Jay Ashworth <jra@baylink.com> wrote:
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view.
Quite simply, its called Tragedy of the Commons. Everyone else has to work harder to provide you services if you are using something which breaks end to end connectivity, which costs everyone else money. The protocol designers are making a stand against this for the good of the "commons".
You'll have to document "everyone has to work harder to provide me services"; this is not my first rodeo, and TTBOMK, it's *transparent* to the other end of any connection out of my edge network that it's NATted at my end. As for incoming connections, it's transparent to them as well -- and which ones are valid targets for such connections *is a policy decision of mine*, not subject to external opinion. Could you clarify, in some detail, precisely how you get to TotC, Blake? Cheers, -- jra
In message <10058800.4297.1296708348990.JavaMail.root@benjamin.baylink.com>, Jay Ashwor th writes:
----- Original Message -----
From: "Blake Dunlap" <ikiris@gmail.com>
On Wed, Feb 2, 2011 at 22:34, Jay Ashworth <jra@baylink.com> wrote:
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view.
Quite simply, its called Tragedy of the Commons. Everyone else has to work harder to provide you services if you are using something which breaks end to end connectivity, which costs everyone else money. The protocol designers are making a stand against this for the good of the "commons".
You'll have to document "everyone has to work harder to provide me services"; this is not my first rodeo, and TTBOMK, it's *transparent* to the other end of any connection out of my edge network that it's NATted at my end.
As for incoming connections, it's transparent to them as well -- and which ones are valid targets for such connections *is a policy decision of mine*, not subject to external opinion.
Could you clarify, in some detail, precisely how you get to TotC, Blake?
Cheers, -- jra
You are going to want the your clients to work well with your NAT. Your vendor is going to have to spend money to do this. The cost of doing this will be passed onto everyone else that buys this client as a direct monetory cost and/or extra complexity in the product. The later also increases the cost in maintaining the product. It also stops the vendor developing other products as it takes additional resources to do this work. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
You'll have to document "everyone has to work harder to provide me services"; this is not my first rodeo, and TTBOMK, it's *transparent* to the other end of any connection out of my edge network that it's NATted at my end.
As for incoming connections, it's transparent to them as well -- and which ones are valid targets for such connections *is a policy decision of mine*, not subject to external opinion.
Could you clarify, in some detail, precisely how you get to TotC, Blake?
You are going to want the your clients to work well with your NAT. Your vendor is going to have to spend money to do this. The cost of doing this will be passed onto everyone else that buys this client as a direct monetory cost and/or extra complexity in the product. The later also increases the cost in maintaining the product. It also stops the vendor developing other products as it takes additional resources to do this work.
So far as I can tell, Mark, the only place where this becomes an issue is in the design of protocols which violate layer independence[1] by baking external transport layer address into fields in higher-layer frames; this in inherently Broken As Designed, and isn't my fault, or problem. I'll point out that such protocols will have to be fixed *anyway*, as transitioning to IPv6 will break them as well. If you merely meant "client operating systems", then I'm going back to "transparent"; please itemize how NAT at the edge of my edge network negatively affects the operations of a client OS, absent the specific broken protocols mentioned above. Next argument? :-) Cheers, -- jra [1] I originally wrote "lawyer independence"; that's funny, but too far off-meaning to leave in. :-)
On Wed, Feb 02, 2011 at 11:45:49PM -0500, Jay Ashworth wrote:
----- Original Message -----
From: "Blake Dunlap" <ikiris@gmail.com>
On Wed, Feb 2, 2011 at 22:34, Jay Ashworth <jra@baylink.com> wrote:
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view.
Quite simply, its called Tragedy of the Commons. Everyone else has to work harder to provide you services if you are using something which breaks end to end connectivity, which costs everyone else money. The protocol designers are making a stand against this for the good of the "commons".
You'll have to document "everyone has to work harder to provide me services"; this is not my first rodeo, and TTBOMK, it's *transparent* to the other end of any connection out of my edge network that it's NATted at my end.
As for incoming connections, it's transparent to them as well -- and which ones are valid targets for such connections *is a policy decision of mine*, not subject to external opinion.
You're thinking too small -- it's not that individual TCP connections have problems, it's that the ability to solve a given problem using connections and UDP packets is badly constrained by a lack of end-to-end connectivity. The proof is fairly obvious in the number of hacks that have been deployed to try and get around NAT's inadequacies: Skype supernodes, STUN, all the various conntrack helpers in netfilters, etc etc etc. Now, if you decide that none of those applications are important to you, sure, you can firewall them off as appropriate. But the pervasive deployment of NAT means that the set of problems that can be solved is constrained, and of the problems that *can* be solved, the solutions tend to be more complicated, harder to implement, understand, and so on, which has a cost to the community (higher prices, less solved problems, whatever your desired metric may be). I think that's what Blake is getting at with his TotC. Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful firewall can know which other connections / packets are related without a lot of the same dodgy shenanigans that goes on now, but at least if you've gotten rid of the 1-to-N address mangling a fundamental stumbling block is removed and people can get on and solve the remaining (tractable) problems. - Matt
----- Original Message -----
From: "Matthew Palmer" <mpalmer@hezmatt.org> You're thinking too small -- it's not that individual TCP connections have problems, it's that the ability to solve a given problem using connections and UDP packets is badly constrained by a lack of end-to-end connectivity. The proof is fairly obvious in the number of hacks that have been deployed to try and get around NAT's inadequacies: Skype supernodes, STUN, all the various conntrack helpers in netfilters, etc etc etc.
At last, some meat. :-)
Now, if you decide that none of those applications are important to you, sure, you can firewall them off as appropriate. But the pervasive deployment of NAT means that the set of problems that can be solved is constrained, and of the problems that *can* be solved, the solutions tend to be more complicated, harder to implement, understand, and so on, which has a cost to the community (higher prices, less solved problems, whatever your desired metric may be). I think that's what Blake is getting at with his TotC.
Perhaps. I'm not sure that the collective importance of that difficulty outweighs the collective danger of making all nodes of the Internet *as it presently exists* publicly routable. I don't know whether it's occurred to people that if you make every node on the present day Internet routable, then *you've made every node on the present day Internet routable*; the number of machines subject to more or less direct attack goes up (by a jackleg estimate I've just now made up) by between 3 and 5 orders of magnitude. I make jackleg estimates all the time; I don't believe I've ever had to say "5 orders of magnitude".
Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful firewall can know which other connections / packets are related without a lot of the same dodgy shenanigans that goes on now, but at least if you've gotten rid of the 1-to-N address mangling a fundamental stumbling block is removed and people can get on and solve the remaining (tractable) problems.
That is problematic as well, isn't it? It speaks directly to the attack-surface comment I just made in another reply. I'm going to bed now, which will reduce the number of replies the "aw crap, is he really going to beat this dead horse again?" crowd will have to skip. :-) Cheers, -- jra
On Thu, Feb 03, 2011 at 12:23:54AM -0500, Jay Ashworth wrote:
----- Original Message -----
From: "Matthew Palmer" <mpalmer@hezmatt.org> Now, if you decide that none of those applications are important to you, sure, you can firewall them off as appropriate. But the pervasive deployment of NAT means that the set of problems that can be solved is constrained, and of the problems that *can* be solved, the solutions tend to be more complicated, harder to implement, understand, and so on, which has a cost to the community (higher prices, less solved problems, whatever your desired metric may be). I think that's what Blake is getting at with his TotC.
Perhaps. I'm not sure that the collective importance of that difficulty outweighs the collective danger of making all nodes of the Internet *as it presently exists* publicly routable.
Well, technically, nodes aren't routable, addresses are... and I don't even see any danger in the mere existence of a valid route to a host. The danger exists when that host is not sufficiently secured (be it via firewall, sensible configuration, whatever).
I don't know whether it's occurred to people that if you make every node on the present day Internet routable, then *you've made every node on the present day Internet routable*; the number of machines subject to more or less direct attack goes up (by a jackleg estimate I've just now made up) by between 3 and 5 orders of magnitude.
I make jackleg estimates all the time; I don't believe I've ever had to say "5 orders of magnitude".
I'm willing to bet you're being deeply optimistic (pessimistic?) with that estimate; if your estimate were accurate, it would mean that for every publically addressed device there are between 1,000 and 100,000 privately addressed nodes. I *really* don't think that's plausible. At any rate, I think the days of severely broken IP stacks and "spectacularly insecure by default" OS installations are largely behind us; the security battle for the "client endpoint" has moved to client-initiated attacks, which are unhindered by NAT, firewalling, or any other "layer-respecting" network security device.
Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful firewall can know which other connections / packets are related without a lot of the same dodgy shenanigans that goes on now, but at least if you've gotten rid of the 1-to-N address mangling a fundamental stumbling block is removed and people can get on and solve the remaining (tractable) problems.
That is problematic as well, isn't it?
It is, but at least it's a problem that has a hope of being solved.
It speaks directly to the attack-surface comment I just made in another reply.
I can't see how. - Matt -- "For once, Microsoft wasn't exaggerating when they named it the 'Jet Engine' -- your data's the seagull." -- Chris Adams
Of course, I'm a tiny bit of a skeptic, as I really can't see how a stateful firewall can know which other connections / packets are related without a lot of the same dodgy shenanigans that goes on now, but at least if you've gotten rid of the 1-to-N address mangling a fundamental stumbling block is removed and people can get on and solve the remaining (tractable) problems.
- Matt
Some applications will still require ALG functionality (or modification) to manage the state in the stateful firewall. The beauty is that this is much simpler if the address and port number on the outside of the stateful firewall are the same as the address and port number inside. It can be reduced, for example to: A->B Connect from A/tcp/29199 to B/tcp/9009 SYN B->A From B/tcp/9009 to A/tcp/29199 SYN ACK A->B From A/tcp/29199 to B/tcp/9009 ACK A->B From A/tcp/29199 to B/tcp/9009 INVITE A/tcp/54450 B->A From A/tcp/9009 to A/tcp/29199 ACCEPT B/tcp/9229 (for A/tcp/54450) B->A From B/tcp/9229 to A/tcp/54450 SYN (ignores if RST in response) A->B From A/tcp/54450 to B/TCP/9229 SYN B->A From B/TCP/9229 to A/tcp/54450 SYN ACK ... Notice how the application was able to poke the holes in both sides because it easily knew the address and port number information since it isn't modified. Both firewalls think that the secondary channel is an outbound connection on both sides. There might be some additional signaling required between the host and the firewall in order to let the firewall know that this is a negotiated connection and the funky combination of states (SYN/SYNACK) is acceptable, but, I think that can be worked around fairly easily. Owen
On 2/3/2011 12:40 AM, Owen DeLong wrote:
Notice how the application was able to poke the holes in both sides because it easily knew the address and port number information since it isn't modified. Both firewalls think that the secondary channel is an outbound connection on both sides.
And the network attack vector with inside spoofing just go even more interesting and easier. Jack
On Feb 2, 2011, at 8:45 PM, Jay Ashworth wrote:
----- Original Message -----
From: "Blake Dunlap" <ikiris@gmail.com>
On Wed, Feb 2, 2011 at 22:34, Jay Ashworth <jra@baylink.com> wrote:
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view.
Quite simply, its called Tragedy of the Commons. Everyone else has to work harder to provide you services if you are using something which breaks end to end connectivity, which costs everyone else money. The protocol designers are making a stand against this for the good of the "commons".
You'll have to document "everyone has to work harder to provide me services"; this is not my first rodeo, and TTBOMK, it's *transparent* to the other end of any connection out of my edge network that it's NATted at my end.
It's not transparent to: Application Developers Operating Systems Home Gateway Developers Consumer Electronics Developers Technical Support departments My users who are trying to talk to your users using applications that are designed to work in a NAT-free world. My technical support department that gets the "we can't reach them" calls from my users who can't reach your users. It may not be your first trip to the rodeo, but, you do appear to have a rather limited perspective on the far reaching detriments of NAT.
As for incoming connections, it's transparent to them as well -- and which ones are valid targets for such connections *is a policy decision of mine*, not subject to external opinion.
Stateful inspection gives you all the same protection for that policy as NAT without breaking the end-to-end model. Nobody is trying to take away your policy rights.
Could you clarify, in some detail, precisely how you get to TotC, Blake?
I think the list of afflicted groups above covers it pretty well. Owen
----- Original Message -----
From: "Owen DeLong" <owen@delong.com>
It's not transparent to: Application Developers Operating Systems Home Gateway Developers Consumer Electronics Developers Technical Support departments My users who are trying to talk to your users using applications that are designed to work in a NAT-free world. My technical support department that gets the "we can't reach them" calls from my users who can't reach your users.
It may not be your first trip to the rodeo, but, you do appear to have a rather limited perspective on the far reaching detriments of NAT.
This is possible. The networks I administer are, admittedly, smaller ones, and they tend to be business-aimed, and thereby have a more strictly limited set of policy-allowed uses... which I've set. Customer transit networks will necessarily expose a larger set of usage... but they also generally (Rose.net notwithstanding) don't apply NAT. I see cogent arguments on both sides of the issue. And my thanks to those on this part of this thread who've supplied actual explanations, rather than merely assertions. Cheers, -- jra
On Wed, Feb 2, 2011 at 10:34 PM, Jay Ashworth <jra@baylink.com> wrote: [snip]
I won't run an edge-network that *isn't* NATted; my internal machines have no business having publicly routable addresses. No one has *ever* provided me with a serviceable explanation as to why that's an invalid view.
If you want to provide an edge network IPv6 connectivity with no routable address space, then use a proxy server / application layer gateway for every allowed application. SOCKS5 can be used to forward any TCP based protocol, and most UDP protocols, other UDP protocols do not actually function correctly in NAT environments anyways (neither do protocols such as FTP which require client side to accept port bound connections). There's no reason for the internet community to re-design every protocol to allow and try to function in a NAT environment, for the benefit of a small number of edge networks, who want a private castle with hosts on their network not connected to the internet, for no reason that has been adequately justified. In IPv4, this had to be accepted, because with limited IP address space, it was not an option to have no NAT. Now with IPv6 it is not an option to have NAT. No one has ever provided me with a serviceable explanation of why a stateful firewall is an insufficient method for implementing any desired network policy, with regards to limiting accepted traffic to outbound connections for nodes on an edge network.
-- jra -- -JH
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
There's no reason for the internet community to re-design every protocol to allow and try to function in a NAT environment, for the benefit of a small number of edge networks, who want a private castle with hosts on their network not connected to the internet, for no reason that has been adequately justified.
Justify, yourself in turn, "small number". My personal estimate of the number of NATted edge networks is well north of 75%, on a network count basis.
No one has ever provided me with a serviceable explanation of why a stateful firewall is an insufficient method for implementing any desired network policy, with regards to limiting accepted traffic to outbound connections for nodes on an edge network.
Complexity of the configuration vastly increases the size of the attack surface: in a NATted edge network, *no packets can come in unless I explicitly configure for them*; there are any number of reasons why an equivalently simply assertion cannot be made concerning the configuration of firewalls, of whatever type or construction. In a firewall, you are *fighting* the default "route this packet" design; in a NATgate, you have to consciously throw the packets over the moat. I've never been clear why this isn't intiutively obvious to the people with whom I have to have this argument. Cheers, -- jra
On Wed, Feb 2, 2011 at 11:18 PM, Jay Ashworth <jra@baylink.com> wrote:
Justify, yourself in turn, "small number". My personal estimate of the number of NATted edge networks is well north of 75%, on a network count
You don't get to count all NAT'ed IPv4 edge networks the same. Only the number of NAT'ed edge networks that decide they don't want to have normal connectivity for their IPs, even with IP address space available to, and even after reading up on IPv6.
Complexity of the configuration vastly increases the size of the attack surface: in a NATted edge network, *no packets can come in unless I explicitly configure for them*; there are any number of
Not necessarily true. This is a case of 'wish it were secure', but can't prove it. It is possible that a client on a NAT'ed network can conspire with an intruder to defeat the NAT device, and in various cases NAT can be completely defeated by an outsider, without a direct conspiracy. Any device on the subnet can spoof a SYN packet from any other device on the subnet. The NAT device will now have a connection entry, and the intruder can use this to circumvent the NAT. A good stateful firewall can prevent this and a few other similar shenanigans. But if the NAT device does not have a true stateful firewall function integrated, it is not nearly as secure as it might at first appear.
In a firewall, you are *fighting* the default "route this packet" design; in a NATgate, you have to consciously throw the packets over the moat.
It sounds like you have a lousy firewall. Decent stateful firewalls deny all incoming traffic by default that does not go with an outbound connection, until policies have been established. It's possible you can make an erroneous access rule, but you can also make an erroneous port forward on a NAT device. -- -JH
On Thu, Feb 3, 2011 at 12:18 AM, Jay Ashworth <jra@baylink.com> wrote:
Complexity of the configuration vastly increases the size of the attack surface: in a NATted edge network, *no packets can come in unless I explicitly configure for them*; there are any number of reasons why an equivalently simply assertion cannot be made concerning the configuration of firewalls, of whatever type or construction.
I've always wondered how many consumer routers aren't actually
On Thu, Feb 3, 2011 at 12:18 AM, Jay Ashworth <jra@baylink.com> wrote:
Complexity of the configuration vastly increases the size of the attack surface: in a NATted edge network, *no packets can come in unless I explicitly configure for them*; there are any number of reasons why an equivalently simply assertion cannot be made concerning the configuration of firewalls, of whatever type or construction.
I've always wondered how many consumer-grade routers aren't actually doing this, and the fact that they don't do this is masked by the use of RFC1918 addresses on the internal side of the router. (Linux with netfilter won't, by default, unless you change the default ACCEPT policy, or add a specific rule to block incoming packets.)
On Wed, 2 Feb 2011, Jimmy Hess wrote:
SOCKS5 can be used to forward any TCP based protocol, and most UDP protocols,
Because SOCKS didn't break things worse than NAT? Really? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On Mon, Jan 31, 2011 at 3:25 PM, bill manning <bmanning@isi.edu> wrote:
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
... whimper ...
Almost a sigh, actually; though in a moment of horrid thread convergence and poor taste, there was some question being tossed around as to whether Egypt's space could be reused, if they're not going to use it after all... :/ Matt
Almost a sigh, actually; though in a moment of horrid thread convergence and poor taste, there was some question being tossed around as to whether Egypt's space could be reused, if they're not going to use it after all... :/
That's sounds like those bad jokes that some jerks tell at a funeral. -J
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.
participants (87)
-
Adam Armstrong -
Adrian Chadd -
Antonio Querubin -
Benson Schliesser -
bill manning -
Blake Dunlap -
bmanning＠vacation.karoshi.com -
Brian Johnson -
Cameron Byrne -
Carlos M. Martinez -
Carlos Martinez-Cagnazzo
-
Chris Adams -
Chris Owen -
Christopher Morrow -
Cutler James R -
Dave CROCKER -
Dave Israel -
David Barak -
David Conrad -
David Israel
-
david raistrick -
Derek J. Balling -
Dorn Hetzel -
Eugen Leitl -
Florian Weimer -
Frank Bulk -
Fred Baker -
Geoff Huston -
George Bonser -
George Herbert -
Greg Estabrooks -
Henry Yen -
Iljitsch van Beijnum -
isabel dias -
Jack Bates -
Jack Carrozzo -
Jared Mauch -
Jay Ashworth -
Jeff Kell -
Jeremy -
Jimmy Hess -
Joe Abley -
Joe Greco -
Joe Provo -
Joel Jaeggli -
John Curran -
John Payne -
Jon Lewis -
Jorge Amodio -
Justin M. Streiner -
Karl Auer -
Kevin Stange -
kmedcalf＠dessus.com -
Lamar Owen -
Lee Howard -
Leo Bicknell -
Majdi S. Abbas -
Mark Andrews -
Mark Smith -
Marshall Eubanks -
Martin Millnert -
Matt Addison -
Matthew Huff -
Matthew Palmer -
Matthew Petach -
Michael Dillon -
Mohacsi Janos -
Nicholas Suan -
Nick Hilliard -
Owen DeLong -
Patrick Greene -
Paul Graydon -
Pekka Savola -
R A Lichtensteiger -
Randy Bush -
Randy Carpenter -
Rene Wilhelm -
Ricky Beam -
Roland Perry -
Scott Helms -
Seth Mattinen -
Simon Lockhart -
Simon Perreault -
Skeeve Stevens -
sthaug＠nethelp.no -
Tony Finch -
Valdis.Kletnieks＠vt.edu