Dear All, We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix. Please any advice regarding the three brands and what are the advantages and disadvantages for each one? Regards,
What features and scale do you need? Assume with NAT you are performing some levels of firewall security and serving applications? Sincerely, Nick Ellermann - CTO & VP Cloud Services BroadAspect E: nellermann@broadaspect.com P: 703-297-4639 F: 703-996-4443 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. -----Original Message----- From: NANOG [mailto:nanog-bounces+nellermann=broadaspect.com@nanog.org] On Behalf Of Ahmed Munaf Sent: Tuesday, December 15, 2015 1:09 PM To: nanog@nanog.org Subject: Nat Dear All, We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix. Please any advice regarding the three brands and what are the advantages and disadvantages for each one? Regards,
You are using a Cisco what for NAT? And which products are you considering? On Tuesday, December 15, 2015, Ahmed Munaf <ahmed.dalaali@hrins.net> wrote:
Dear All,
We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.
Please any advice regarding the three brands and what are the advantages and disadvantages for each one?
Regards,
Yes, we are using ASR1004 for NAT, we are considering A10 or Citrix or F5. we’ve not decided till now! maybe we change it to another product, if anyone give us a better solution. this will be used for ISP’s users.
On Dec 16, 2015, at 4:15 AM, Hunter Fuller <hf0002+nanog@uah.edu> wrote:
You are using a Cisco what for NAT? And which products are you considering?
On Tuesday, December 15, 2015, Ahmed Munaf <ahmed.dalaali@hrins.net <mailto:ahmed.dalaali@hrins.net>> wrote: Dear All,
We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.
Please any advice regarding the three brands and what are the advantages and disadvantages for each one?
Regards,
On 16/Dec/15 12:45, Ahmed Munaf wrote:
Yes, we are using ASR1004 for NAT, we are considering A10 or Citrix or F5. we’ve not decided till now! maybe we change it to another product, if anyone give us a better solution.
this will be used for ISP’s users.
The ASR1000 is not a bad large scale NAT device. Are there any specific issues you are facing with it? Mark.
In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems! Ahmed,
On Dec 16, 2015, at 7:22 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Dec/15 12:45, Ahmed Munaf wrote:
Yes, we are using ASR1004 for NAT, we are considering A10 or Citrix or F5. we’ve not decided till now! maybe we change it to another product, if anyone give us a better solution.
this will be used for ISP’s users.
The ASR1000 is not a bad large scale NAT device. Are there any specific issues you are facing with it?
Mark.
On 16/Dec/15 18:36, Ahmed Munaf wrote:
In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems!
This could be a function of the size of your ESP. The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP will do 4,000,000 NAT sessions with a per-second setup rate of 300,000 sessions. Of course, it makes little sense to upgrade if you run out of sessions before you hit the NAT throughput ceiling, so other vendors may be more commercially palatable. Mark.
On Dec 16, 2015, at 7:52 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Dec/15 18:36, Ahmed Munaf wrote:
In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems!
This could be a function of the size of your ESP.
The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP will do 4,000,000 NAT sessions with a per-second setup rate of 300,000 sessions.
Of course, it makes little sense to upgrade if you run out of sessions before you hit the NAT throughput ceiling, so other vendors may be more commercially palatable.
Mark.
Thats right but as you mentioned that its commercially palatable, however I don’t know if the other vendors are the same performance as ASR1000! this was my question if someone recommend another vendor.
At $dayjob$ (which is a university) we spoke to several vendors and eventually gave A10 Networks Thunder 3030 a test drive. It satisfied our requirements and fit our budget. Most of our NAT traffic originates from our undergraduate student population. Peak workload during 2015 fall term was about 27k concurrently active devices, 4.6Gbps, 415kpps. The ASR1000 would have been our other choice but the ASR's higher price pushed us toward A10. Eriks --- Eriks Rugelis Sr. Consultant Netidea Inc. T: +1.416.876.0740
On Dec 17, 2015, at 12:30, Ahmed Munaf <ahmed.dalaali@hrins.net> wrote:
On Dec 16, 2015, at 7:52 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Dec/15 18:36, Ahmed Munaf wrote:
In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems!
This could be a function of the size of your ESP.
The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP will do 4,000,000 NAT sessions with a per-second setup rate of 300,000 sessions.
Of course, it makes little sense to upgrade if you run out of sessions before you hit the NAT throughput ceiling, so other vendors may be more commercially palatable.
Mark.
Thats right but as you mentioned that its commercially palatable, however I don’t know if the other vendors are the same performance as ASR1000! this was my question if someone recommend another vendor.
Thanks, we are speaking with few vendors and A10 one of them. they offer the model Thunder 3030S, the price was good in comparison with the specifications of this model. its good to know that it works good at your university.
On Dec 17, 2015, at 9:34 PM, Netideainc <eriks@netideainc.ca> wrote:
At $dayjob$ (which is a university) we spoke to several vendors and eventually gave A10 Networks Thunder 3030 a test drive.
It satisfied our requirements and fit our budget. Most of our NAT traffic originates from our undergraduate student population. Peak workload during 2015 fall term was about 27k concurrently active devices, 4.6Gbps, 415kpps.
The ASR1000 would have been our other choice but the ASR's higher price pushed us toward A10.
Eriks --- Eriks Rugelis Sr. Consultant Netidea Inc. T: +1.416.876.0740
On Dec 17, 2015, at 12:30, Ahmed Munaf <ahmed.dalaali@hrins.net> wrote:
On Dec 16, 2015, at 7:52 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 16/Dec/15 18:36, Ahmed Munaf wrote:
In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems!
This could be a function of the size of your ESP.
The 5Gbps ESP can handle 256,000 NAT sessions, while the 200Gbps ESP will do 4,000,000 NAT sessions with a per-second setup rate of 300,000 sessions.
Of course, it makes little sense to upgrade if you run out of sessions before you hit the NAT throughput ceiling, so other vendors may be more commercially palatable.
Mark.
Thats right but as you mentioned that its commercially palatable, however I don’t know if the other vendors are the same performance as ASR1000! this was my question if someone recommend another vendor.
We have the ASR1006 ESP40's handling 25,000+home broadband users running NAT and barely breaking a sweat. What ESP are you using ? -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ahmed Munaf Sent: Thursday, 17 December 2015 5:36 AM To: Mark Tinka <mark.tinka@seacom.mu> Cc: nanog@nanog.org Subject: Re: Nat In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems! Ahmed,
we are using ESP 20
On Dec 16, 2015, at 10:46 PM, Tony Wicks <tony@wicks.co.nz> wrote:
We have the ASR1006 ESP40's handling 25,000+home broadband users running NAT and barely breaking a sweat. What ESP are you using ?
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Ahmed Munaf Sent: Thursday, 17 December 2015 5:36 AM To: Mark Tinka <mark.tinka@seacom.mu> Cc: nanog@nanog.org Subject: Re: Nat
In addition to the limited concurrent sessions for ASR1000, we are facing some issue with many users how are playing online games! Nat problems!
Ahmed,
On 17/12/2015 17:36, Ahmed Munaf wrote:
we are using ESP 20
You haven't said what you mean by "better". This could mean "faster" or "copes with more sessions" or "cheaper". If your ISP is large, then it might be "cost per user is lower" or "able to cope with the number of users". Nick
On Dec 17, 2015, at 8:47 PM, Nick Hilliard <nick@foobar.org> wrote:
On 17/12/2015 17:36, Ahmed Munaf wrote:
we are using ESP 20
You haven't said what you mean by "better". This could mean "faster" or "copes with more sessions" or "cheaper". If your ISP is large, then it might be "cost per user is lower" or "able to cope with the number of users".
Nick
I mean by better, it handle more sessions and cheaper
On Fri, Dec 18, 2015 at 07:30:35PM +0300, Ahmed Munaf wrote:
On Dec 17, 2015, at 8:47 PM, Nick Hilliard <nick@foobar.org> wrote:
On 17/12/2015 17:36, Ahmed Munaf wrote:
we are using ESP 20
You haven't said what you mean by "better". This could mean "faster" or "copes with more sessions" or "cheaper". If your ISP is large, then it might be "cost per user is lower" or "able to cope with the number of users".
I mean by better, it handle more sessions and cheaper
At what scale? You probably won't get much cheaper than an rPi and netfilter at home scale, but I wouldn't want to run a national ISP on one. Also, by "cheaper" do you just mean capex, or is opex a concern? - Matt
On 15/12/15 10:08, Ahmed Munaf wrote:
Dear All,
We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.
If you are willing to rephrase it to "we are using Cisco IOS for NATting, we'd like to change it to another platform or brand", you may want to take a look at Cisco ASAs. In my opinion those are better NATters than IOS. Best regards.
IPv4 NAT!? Free yourself from the tyranny of shared addresses. ;-) http://www.comcast6.net/images/files/revolt.jpg Jason On 12/15/15, 1:08 PM, "NANOG on behalf of Ahmed Munaf" <nanog-bounces+jason_livingood=cable.comcast.com@nanog.org on behalf of ahmed.dalaali@hrins.net> wrote:
Dear All,
We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.
Please any advice regarding the three brands and what are the advantages and disadvantages for each one?
Regards,
If it were only so easy... On Dec 16, 2015 4:41 PM, "Livingood, Jason" < Jason_Livingood@cable.comcast.com> wrote:
IPv4 NAT!? Free yourself from the tyranny of shared addresses. ;-)
http://www.comcast6.net/images/files/revolt.jpg
Jason
On 12/15/15, 1:08 PM, "NANOG on behalf of Ahmed Munaf" <nanog-bounces+jason_livingood=cable.comcast.com@nanog.org on behalf of ahmed.dalaali@hrins.net> wrote:
Dear All,
We are using cisco for natting, we'd like to change it to another brand like A10 or Citrix.
Please any advice regarding the three brands and what are the advantages and disadvantages for each one?
Regards,
+1000000 Nobody should have to be doing NAT today. We need to make IPv4 painful to use. Adding delay between SYN and SYN/ACK would be one way to achieve this. Start at 100ms..200ms and increase it by 100ms each year. Mark On 17/12/2015, at 9:38 AM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com> wrote:
IPv4 NAT!? Free yourself from the tyranny of shared addresses. ;-)
http://www.comcast6.net/images/files/revolt.jpg
Jason
This doesn't put pain on those that have enough addresses that they don't need to NAT yet. We need to put some pain onto everyone that is IPv4 only. Mark On 17/12/2015, at 10:39 AM, Charles Monson <charles.lists@camonson.com> wrote:
We need to make IPv4 painful to use. Adding delay between SYN and SYN/ACK would be one way to achieve this. Start at 100ms..200ms and increase it by 100ms each year.
It seems like NAT would be another way to make IPv4 more painful to use.
Mark, Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually. I don't like what you eat. Lets put a surcharge on it to make you feel pain and do what I want. :) -mel beckman
On Dec 16, 2015, at 3:55 PM, Mark Andrews <marka@isc.org> wrote:
This doesn't put pain on those that have enough addresses that they don't need to NAT yet. We need to put some pain onto everyone that is IPv4 only.
Mark
On 17/12/2015, at 10:39 AM, Charles Monson <charles.lists@camonson.com> wrote:
We need to make IPv4 painful to use. Adding delay between SYN and SYN/ACK would be one way to achieve this. Start at 100ms..200ms and increase it by 100ms each year.
It seems like NAT would be another way to make IPv4 more painful to use.
On 12/16/2015 18:14, Mel Beckman wrote:
Mark,
Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually.
I don't like what you eat. Lets put a surcharge on it to make you feel pain and do what I want. :)
That's what I'm talking about. But this IS right out of the current government's handbook. -- sed quis custodiet ipsos custodes? (Juvenal)
While we will get us there eventually it will be at the considerably more expensive for everyone involved. There is also a distinct lack of a working free market in most of the world. There isn't one in Australia. From what I read there isn't one in most of the developed nations in the world including the US. Mark On 17/12/2015, at 11:14 AM, Mel Beckman <mel@beckman.org> wrote:
Mark,
Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually.
I don't like what you eat. Lets put a surcharge on it to make you feel pain and do what I want. :)
-mel beckman
On Dec 16, 2015, at 3:55 PM, Mark Andrews <marka@isc.org> wrote:
This doesn't put pain on those that have enough addresses that they don't need to NAT yet. We need to put some pain onto everyone that is IPv4 only.
Mark
On 17/12/2015, at 10:39 AM, Charles Monson <charles.lists@camonson.com> wrote:
We need to make IPv4 painful to use. Adding delay between SYN and SYN/ACK would be one way to achieve this. Start at 100ms..200ms and increase it by 100ms each year.
It seems like NAT would be another way to make IPv4 more painful to use.
On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman" <nanog-bounces@nanog.org on behalf of mel@beckman.org> wrote:
Mark,
Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually.
Some companies will run out of IPv4 addresses before others. When that happens, they have four choices: 1. Buy IPv4 addresses. But supply is going; in a couple of years, there will be nothing larger than a /16. And this raises costs, and therefore consumer prices. 2. Address sharing. Breaks p2p, some other things. 3. Address family translation. Breaks several things. 4. IPv6-only. Means only IPv6-enabled content is available. That¹s why some values of $we ³need² to force people to deploy IPv6: so $we don¹t screw consumers and break the Internet. But those with IPv4 addresses see exhaustion as someone else¹s problem. They don¹t care if somebody else¹s prices go up, unless they¹re the ones blamed for the rising prices. (³You have to pay more for Internet access or you won¹t be able to reach Amazon or eBay.²) They might not like the performance of address sharing/translation, but if they wait until they notice the pain, and it takes them two years to respond, they¹re already in serious trouble. There is still time for companies without IPv6 to get it deployed before going out of business. But anyone who isn¹t done two years from now is in trouble. Lee
On Dec 18, 2015, at 13:35 , Lee Howard <Lee@asgard.org> wrote:
On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman" <nanog-bounces@nanog.org on behalf of mel@beckman.org> wrote:
Mark,
Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually.
Not all problems are well solved by markets, contrary to popular dogma. In this case, those with the least ability to affect the outcome overall are the ones with the greatest need for IPv6. Large incumbent organizations that have lots of IPv4 addresses already have very little tangible market incentive to move, yet until they move, it’s very difficult for smaller players to operate without IPv4 even though it’s now very hard for them to get IPv4 addresses. As such, it’s incumbent on each and every one of us to try and resolve this globally so as to reduce the lasting impacts of our dependence on IPv4 globally. Owen
In message <D299E31B.D159F%Lee@asgard.org>, Lee Howard writes:
On 12/16/15, 7:14 PM, "NANOG on behalf of Mel Beckman" <nanog-bounces@nanog.org on behalf of mel@beckman.org> wrote:
Mark,
Why? Why do WE "need" to force people to bend to our will? The market will get us all there eventually.
Some companies will run out of IPv4 addresses before others. When that happens, they have four choices:
1. Buy IPv4 addresses. But supply is going; in a couple of years, there will be nothing larger than a /16. And this raises costs, and therefore consumer prices. 2. Address sharing. Breaks p2p, some other things. 3. Address family translation. Breaks several things. 4. IPv6-only. Means only IPv6-enabled content is available.
Additionally just because you have enough IPv4 addresses it doesn't mean that the other end has a IPv4 address that is not shared with multiple customers. You can't connect to them. The ISP industry has totally !@#$$!@$ over the customers for too long. It should have made available IPv6 to everyone before the first RIR ran out of addresses. Everyone of you that has not delivered IPv6 to your customers already should be ashamed to call yourself a ISP because you definitely have stopped delivering the Internet to your customers (you only deliver half the Internet), you have not Provided the Service that they need to be able to connect to everyone out there in the world. When your customers purchase a Internet connection they *expect* to be able to reach *everyone* not just those that have a IPv4 address to themselves because they don't care about IPv4 vs IPv6. They just want to be able to reach everyone that is on the Internet and it is your *job* to deliver that. Thats what you get *paid* to do. Not doing that is *fraud*. It's time governments started issuing large fines for false advertising for failure to make available IPv6 to your customers.
That's why some values of $we "need" to force people to deploy IPv6: so $we don't screw consumers and break the Internet.
But those with IPv4 addresses see exhaustion as someone else's problem. They don't care if somebody else's prices go up, unless they're the ones blamed for the rising prices. ("You have to pay more for Internet access or you won't be able to reach Amazon or eBay.") They might not like the performance of address sharing/translation, but if they wait until they notice the pain, and it takes them two years to respond, they're already in serious trouble.
There is still time for companies without IPv6 to get it deployed before going out of business. But anyone who isn't done two years from now is in trouble.
Lee
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
We need to put some pain onto everyone that is IPv4 only.
this is the oppress the workers so they will revolt theory. load of crap. make ipv6 easier to deploy, especially in enterprise. repeat the previous sentence 42 times. what keeps the cows in the pasture is the quality of the grass not the height of the fence. randy
At 08:22 PM 12/16/2015, Randy Bush wrote:
We need to put some pain onto everyone that is IPv4 only.
this is the oppress the workers so they will revolt theory. load of crap.
make ipv6 easier to deploy, especially in enterprise. repeat the previous sentence 42 times.
This. I'm in an enterprise with some stubborn vendors, and none of them are even talking about ipv6. It won't help me to move (and it won't help you to get well if you're here) if my users can't get to their stuff. Berry
On Wed, Dec 16, 2015 at 5:22 PM, Randy Bush <randy@psg.com> wrote:
We need to put some pain onto everyone that is IPv4 only.
this is the oppress the workers so they will revolt theory.
Ah, yes, the workers are quite revolting!
load of crap.
make ipv6 easier to deploy, especially in enterprise. repeat the previous sentence 42 times.
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of. Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
what keeps the cows in the pasture is the quality of the grass not the height of the fence.
randy
Randy, I would happily appoint you as CIG-Q, the Chief Inspector of Grass Quality. ;) Matt
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matthew Petach Sent: Thursday, December 17, 2015 1:59 PM Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: Nat
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP.
And that recent thread on prefix delegation doesn't really leave a good taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and get that/those prefix(s) in your (ISP) routing tables. Given that 99.999% of home users would be fine with a delegation of a single /64 and a single subnet I'm tempted to do that for now and let the DHCP-PD ink dry for a while so CPE support can follow up. Chuck
In message <01de01d13900$fe364dd0$faa2e970$@gmail.com>, "Chuck Church" writes:
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matthew Petach Sent: Thursday, December 17, 2015 1:59 PM Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: Nat
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP.
And that recent thread on prefix delegation doesn't really leave a good taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and get that/those prefix(s) in your (ISP) routing tables. Given that 99.999% of home users would be fine with a delegation of a single /64 and a single subnet I'm tempted to do that for now and let the DHCP-PD ink dry for a while so CPE support can follow up.
I have a single CPE router and 3 /64's in use. One for each of the wireless SSID's and one for the wired network. This is the default for homenet devices. A single /64 means you have to bridge all the traffic. A single /64 has never been enough and it is time to grind that myth into the ground. ISP's that say a single /64 is enough are clueless. Mark
Chuck
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
"A single /64 has never been enough and it is time to grind that myth into the ground. ISP's that say a single /64 is enough are clueless." LLLLOOOOOOLLLLL A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Mark Andrews" <marka@isc.org> To: "Chuck Church" <chuckchurch@gmail.com> Cc: "North American Network Operators' Group" <nanog@nanog.org> Sent: Thursday, December 17, 2015 6:46:13 PM Subject: Re: Nat In message <01de01d13900$fe364dd0$faa2e970$@gmail.com>, "Chuck Church" writes:
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matthew Petach Sent: Thursday, December 17, 2015 1:59 PM Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: Nat
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP.
And that recent thread on prefix delegation doesn't really leave a good taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and get that/those prefix(s) in your (ISP) routing tables. Given that 99.999% of home users would be fine with a delegation of a single /64 and a single subnet I'm tempted to do that for now and let the DHCP-PD ink dry for a while so CPE support can follow up.
I have a single CPE router and 3 /64's in use. One for each of the wireless SSID's and one for the wired network. This is the default for homenet devices. A single /64 means you have to bridge all the traffic. A single /64 has never been enough and it is time to grind that myth into the ground. ISP's that say a single /64 is enough are clueless. Mark
Chuck
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Hi,
On Dec 19, 2015, at 11:41 AM, Mike Hammett <nanog@ics-il.net> wrote:
"A single /64 has never been enough and it is time to grind that myth into the ground. ISP's that say a single /64 is enough are clueless."
LLLLOOOOOOLLLLL
A 100 gallon fuel tank is fine for most forms of transportation most people think of. For some reason we built IPv6 like a fighter jet requiring everyone have 10,000 gallon fuel tanks... for what purpose remains to be seen, if ever.
You’re being deliberately flippant. There are technical reasons why a single /64 is not enough for an end user. A lot of it has to do with the way auto configuration works. The lower 64 bits of the IP address are essentially host entropy. EUI-64 (for example) is a 64 bit number derived from the mac address of the NIC. The requirement for the host portion of the address to be 64 bits long isn’t likely to change. Which means a /64 is the smallest possible prefix that can be assigned to an end user and it limits said end user to a single subnet. Handing out a /56 or a /48 allows the customer premise equipment to have multiple networks behind it. It’s a good practice and there’s certainly enough address space available to support it.
-----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: Thursday, December 17, 2015 7:46 PM To: Chuck Church <chuckchurch@gmail.com> Cc: 'Matthew Petach' <mpetach@netflight.com>; 'North American Network Operators' Group' <nanog@nanog.org> Subject: Re: Nat
I have a single CPE router and 3 /64's in use. One for each of the wireless SSID's and one for the wired network. This is the default for homenet devices. A single /64 means you >have to bridge all the traffic.
A single /64 has never been enough and it is time to grind that myth into the ground. ISP's that say a single /64 is enough are clueless.
Mark, I agree that a /48 or /56 being reserved for business customers/sites is reasonable. But for residential use, I'm having a hard time believing multi-subnet home networks are even remotely common outside of networking folk such as the NANOG members. A lot of recent IPv4 devices such as smart TVs have the ability to auto-discover things they can talk to on the network. If we start segmenting our home networks to keep toasters from talking to thermostats, doesn't this end up meaning your average home user will need to be proficient in writing FW rules? Bridging an entire house network isn't that bad. Chuck
I agree that a /48 or /56 being reserved for business customers/sites is reasonable. But for residential use, I'm having a hard time believing multi-subnet home networks are even remotely common outside of networking folk such as the NANOG members. A lot of recent IPv4 devices such as smart TVs have the ability to auto-discover things they can talk to on the network. If we start segmenting our home networks to keep toasters from talking to thermostats, doesn't this end up meaning your average home user will need to be proficient in writing FW rules? Bridging an entire house network isn't that bad.
I have (currently) 6 network segments. One for my "trusted" clients, one for my "trusted" servers, one for the "entertainment" systems, one for "dirty & untrustworthy" computers (such as those from $dayjob), one for "clean" WiFi, and one for dirty WiFi. If there were any additional classes of devices, they would live in their own subnets as well. I cannot habituation between classes of devices on the same network segment. Untrustworthy devices are relegated to their own segments where they cannot talk to anything that they ought not be talking to. Of course, your definition of "untrustworthy" may not be the same as mine. Any device over which I do not have supreme complete authority is untrustworthy -- which by definition includes most entertainment and other "Internet-of-Crap" devices.
Most people couldn't care less and just want the Internet on their device to work. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: nanog@nanog.org Sent: Sunday, December 20, 2015 9:11:53 PM Subject: RE: Nat
I agree that a /48 or /56 being reserved for business customers/sites is reasonable. But for residential use, I'm having a hard time believing multi-subnet home networks are even remotely common outside of networking folk such as the NANOG members. A lot of recent IPv4 devices such as smart TVs have the ability to auto-discover things they can talk to on the network. If we start segmenting our home networks to keep toasters from talking to thermostats, doesn't this end up meaning your average home user will need to be proficient in writing FW rules? Bridging an entire house network isn't that bad.
I have (currently) 6 network segments. One for my "trusted" clients, one for my "trusted" servers, one for the "entertainment" systems, one for "dirty & untrustworthy" computers (such as those from $dayjob), one for "clean" WiFi, and one for dirty WiFi. If there were any additional classes of devices, they would live in their own subnets as well. I cannot habituation between classes of devices on the same network segment. Untrustworthy devices are relegated to their own segments where they cannot talk to anything that they ought not be talking to. Of course, your definition of "untrustworthy" may not be the same as mine. Any device over which I do not have supreme complete authority is untrustworthy -- which by definition includes most entertainment and other "Internet-of-Crap" devices.
On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett <nanog@ics-il.net> wrote:
Most people couldn't care less and just want the Internet on their device to work.
Well, if the best practice for CPE routers included as a matter of course the subnets "connected to internet", "local only (e.g. IoT)" and "guest network", and if they just worked, then they wouldn't mind that either. A friend of mine used to refer to this as 'refrigerator consciousness" - he was a gearhead, so it was a pejorative. Instead, I think of it as a design goal. -Randy Fischer
We can't get people to use passwords judiciously (create them at all for WiFi, change them, use more than one, etc.) and now you want them to manage networks? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Randy Fischer" <randy.fischer@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "North American Network Operators Group" <nanog@nanog.org> Sent: Sunday, December 20, 2015 9:34:16 PM Subject: Re: Nat On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog@ics-il.net > wrote: Most people couldn't care less and just want the Internet on their device to work. Well, if the best practice for CPE routers included as a matter of course the subnets "connected to internet", "local only (e.g. IoT)" and "guest network", and if they just worked, then they wouldn't mind that either. A friend of mine used to refer to this as 'refrigerator consciousness" - he was a gearhead, so it was a pejorative. Instead, I think of it as a design goal. -Randy Fischer
You can lead a horse to water, but you cannot make it drink. If people choose to be the authors of their own misfortunes, that is their choice. I know a good many folks who are not members of NANOG yet have multiple separate L2 and L3 networks to keep the "crap" isolated.
-----Original Message----- From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com@nanog.org] On Behalf Of Mike Hammett Sent: Sunday, 20 December, 2015 20:37 Cc: North American Network Operators Group Subject: Re: Nat
We can't get people to use passwords judiciously (create them at all for WiFi, change them, use more than one, etc.) and now you want them to manage networks?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
----- Original Message -----
From: "Randy Fischer" <randy.fischer@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "North American Network Operators Group" <nanog@nanog.org> Sent: Sunday, December 20, 2015 9:34:16 PM Subject: Re: Nat
On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog@ics-il.net > wrote:
Most people couldn't care less and just want the Internet on their device to work.
Well, if the best practice for CPE routers included as a matter of course the subnets "connected to internet", "local only (e.g. IoT)" and "guest network", and if they just worked, then they wouldn't mind that either.
A friend of mine used to refer to this as 'refrigerator consciousness" - he was a gearhead, so it was a pejorative. Instead, I think of it as a design goal.
-Randy Fischer
In the real world of service providers and customers, people don't "choose to be the authors". To choose, they would have to know the options. If I were to randomly poll 1000 of our residential customers to ask them about their L2/L3 networks, firewall policies, etc..., they'd have no idea what I was talking about. The majority of our small business customers are in the same situation. The larger businesses with their own IT staff are in a little better shape. The network consultants in the area barely understand these subjects better than their customers. Whether we're talking about Joe Sixpack or John SMB, they pay for a service and expect that service to magically work. They've used phones for years without understanding the PSTN. We gave them cellphones without making them understand RF/LTE/GPRS/etc.... They drive cars every day without the first clue about how internal combustion engines work. Why should data networks be any different? Sure, I'm oversimplifying things, but that's how non-technical people think. They should be able to spend money on cool and/or useful gadgets, connect those gadgets to their networks, and use them. It's tough enough to try and explain why the neighbor's wi-fi parked on channel 8 is an interferer. L2, L3, IPv4/6 and Multicast? Good luck.
From a service provider perspective, I feel we have 2 choices. The first is to spend a lot of time trying to educate our customers on how networks work and how to manage theirs. Personally, I'd rather have my fingernails pulled out. The second, and I feel much less likely to fail, is to spend time developing technology and service offerings to give our customers the easy, spoon-fed experience they're looking for - and charge them for it accordingly.
On Sun, Dec 20, 2015 at 10:06 PM, Keith Medcalf <kmedcalf@dessus.com> wrote:
You can lead a horse to water, but you cannot make it drink. If people choose to be the authors of their own misfortunes, that is their choice. I know a good many folks who are not members of NANOG yet have multiple separate L2 and L3 networks to keep the "crap" isolated.
-----Original Message----- From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com@nanog.org] On Behalf Of Mike Hammett Sent: Sunday, 20 December, 2015 20:37 Cc: North American Network Operators Group Subject: Re: Nat
We can't get people to use passwords judiciously (create them at all for WiFi, change them, use more than one, etc.) and now you want them to manage networks?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
----- Original Message -----
From: "Randy Fischer" <randy.fischer@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "North American Network Operators Group" <nanog@nanog.org> Sent: Sunday, December 20, 2015 9:34:16 PM Subject: Re: Nat
On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog@ics-il.net > wrote:
Most people couldn't care less and just want the Internet on their device to work.
Well, if the best practice for CPE routers included as a matter of course the subnets "connected to internet", "local only (e.g. IoT)" and "guest network", and if they just worked, then they wouldn't mind that either.
A friend of mine used to refer to this as 'refrigerator consciousness" - he was a gearhead, so it was a pejorative. Instead, I think of it as a design goal.
-Randy Fischer
On 21/Dec/15 07:22, Jason Baugher wrote:
From a service provider perspective, I feel we have 2 choices. The first is to spend a lot of time trying to educate our customers on how networks work and how to manage theirs. Personally, I'd rather have my fingernails pulled out. The second, and I feel much less likely to fail, is to spend time developing technology and service offerings to give our customers the easy, spoon-fed experience they're looking for - and charge them for it accordingly.
+1. Car manufacturers gave us ABS, instead of lengthy manuals about how to brake effectively in the wet. Mark.
Hello, Does anyone use Citrix Netscaler MPX 14000 as a CGNAT for more than 25K users? Regards,
It simply is not common and will not become common. Not everyone is a network engineer. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Keith Medcalf" <kmedcalf@dessus.com> To: nanog@nanog.org Sent: Sunday, December 20, 2015 10:06:26 PM Subject: RE: Nat You can lead a horse to water, but you cannot make it drink. If people choose to be the authors of their own misfortunes, that is their choice. I know a good many folks who are not members of NANOG yet have multiple separate L2 and L3 networks to keep the "crap" isolated.
-----Original Message----- From: NANOG [mailto:nanog-bounces+kmedcalf=dessus.com@nanog.org] On Behalf Of Mike Hammett Sent: Sunday, 20 December, 2015 20:37 Cc: North American Network Operators Group Subject: Re: Nat
We can't get people to use passwords judiciously (create them at all for WiFi, change them, use more than one, etc.) and now you want them to manage networks?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
----- Original Message -----
From: "Randy Fischer" <randy.fischer@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "North American Network Operators Group" <nanog@nanog.org> Sent: Sunday, December 20, 2015 9:34:16 PM Subject: Re: Nat
On Sun, Dec 20, 2015 at 10:15 PM, Mike Hammett < nanog@ics-il.net > wrote:
Most people couldn't care less and just want the Internet on their device to work.
Well, if the best practice for CPE routers included as a matter of course the subnets "connected to internet", "local only (e.g. IoT)" and "guest network", and if they just worked, then they wouldn't mind that either.
A friend of mine used to refer to this as 'refrigerator consciousness" - he was a gearhead, so it was a pejorative. Instead, I think of it as a design goal.
-Randy Fischer
On Sun, Dec 20, 2015 at 08:11:53PM -0700, Keith Medcalf wrote:
I agree that a /48 or /56 being reserved for business customers/sites is reasonable. But for residential use, I'm having a hard time believing multi-subnet home networks are even remotely common outside of networking folk such as the NANOG members. A lot of recent IPv4 devices such as smart TVs have the ability to auto-discover things they can talk to on the network. If we start segmenting our home networks to keep toasters from talking to thermostats, doesn't this end up meaning your average home user will need to be proficient in writing FW rules? Bridging an entire house network isn't that bad.
I have (currently) 6 network segments. One for my "trusted" clients, one for my "trusted" servers, one for the "entertainment" systems, one for "dirty & untrustworthy" computers (such as those from $dayjob), one for "clean" WiFi, and one for dirty WiFi. If there were any additional classes of devices, they would live in their own subnets as well.
If suspect you probably come under the "networking folk such as NANOG members" exception to the general assertion. - Matt
On Sun, Dec 20, 2015 at 09:23:04PM -0500, Chuck Church wrote:
I agree that a /48 or /56 being reserved for business customers/sites is reasonable. But for residential use, I'm having a hard time believing multi-subnet home networks are even remotely common outside of networking folk such as the NANOG members. A lot of recent IPv4 devices such as smart TVs have the ability to auto-discover things they can talk to on the network. If we start segmenting our home networks to keep toasters from talking to thermostats, doesn't this end up meaning your average home user will need to be proficient in writing FW rules? Bridging an entire house network isn't that bad.
Depends on how many devices you have on it. Once you start filling your home with Internet of Unpatchable Security Holes devices, having everything on a single ethernet segment might start to get a little... noisy. Thankfully, IPv6 has well-defined multicast scopes, which makes it trivially easy to do cross-L2-segment service discovery without needing to resort to manually berking around with firewall rules. - Matt
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matt Palmer Sent: Sunday, December 20, 2015 10:29 PM To: nanog@nanog.org Subject: Re: Nat
Depends on how many devices you have on it. Once you start filling your home with Internet of Unpatchable Security Holes devices, having everything on a single ethernet >segment might start to get a little... noisy.
Thankfully, IPv6 has well-defined multicast scopes, which makes it trivially easy to do cross-L2-segment service discovery without needing to resort to manually berking around >with firewall rules.
- Matt
If your home is full of unpatched or compromised hosts, and they're using these well-defined multicast scopes, doesn't that mean they can now communicate and infect one another? For years I've seen people on this list insist on "NAT/PAT != firewall". Well, a router routing everything it sees is even less of a firewall. I'm really not trying to be argumentative here, but I'm just having a hard time believing Joe Sixpack will be applying business networking principals such as micro-segmenting to a home network with 3 to 7 devices on it. If anything, these complexities we keep adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing down the general deployment of IPv6. Chuck
On Sun, Dec 20, 2015 at 10:54:49PM -0500, Chuck Church wrote:
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matt Palmer
Depends on how many devices you have on it. Once you start filling your home with Internet of Unpatchable Security Holes devices, having everything on a single ethernet >segment might start to get a little... noisy.
Thankfully, IPv6 has well-defined multicast scopes, which makes it trivially easy to do cross-L2-segment service discovery without needing to resort to manually berking around >with firewall rules.
If your home is full of unpatched or compromised hosts, and they're using these well-defined multicast scopes, doesn't that mean they can now communicate and infect one another?
No, multicast for discovery doesn't necessarily mean that the application traffic can also pass. The discovery multicast packets could be filtered at any point within the network, also. However, access control isn't what you asked about. You claimed that multiple L2 segments broke service discovery, and I refuted that point.
For years I've seen people on this list insist on "NAT/PAT != firewall". Well, a router routing everything it sees is even less of a firewall.
Correct. However, nowhere did I suggest that a router should be routing absolutely everything it sees.
I'm really not trying to be argumentative here,
And yet, you're doing an awfully good job of being argumentative, about a subject you really don't seem to know a whole lot about.
but I'm just having a hard time believing Joe Sixpack will be applying business networking principals such as micro-segmenting to a home network with 3 to 7 devices on it. If anything, these complexities we keep adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing down the general deployment of IPv6.
Yes, it's a pity that people who refuse to learn about the new features that IPv6 provides keep trying to shoehorn IPv6 into their legacy mindset, but there's not a whole lot the rest of us can do about that. - Matt
On Sun, 20 Dec 2015, Chuck Church wrote:
insist on "NAT/PAT != firewall". Well, a router routing everything it sees is even less of a firewall. I'm really not trying to be argumentative here, but I'm just having a hard time believing Joe Sixpack will be applying business networking principals such as micro-segmenting to a home network with 3 to 7 devices on it. If anything, these complexities we keep
I'm not disagreeing, but as this came up recently in another forum, I think you'll find that most home networks have a couple times that number of networked devices...once you add up computers, phones, tablets, game consoles, TV's & other media devices, thermostats, cameras, security systems, you'll probably run out of fingers and toes counting them all in a typical home network. The average home user wouldn't know what you were talking about though if you asked them if they wanted to put various device classes in different subnets. They just want it all to work...and keeping it all working means providing at least a default level of security/filtering that prevents all of it from being directly accessed by remote scanners looking to exploit insecure systems.
adding/debating such as DHCP vs RA, prefix delegation, etc are only slowing down the general deployment of IPv6.
From my perspective, ISP's not offering v6 is what's slowing down deployment. My home cable provider still does not.
---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
In message <00e801d13b96$873e1120$95ba3360$@gmail.com>, "Chuck Church" writes:
-----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: Thursday, December 17, 2015 7:46 PM To: Chuck Church <chuckchurch@gmail.com> Cc: 'Matthew Petach' <mpetach@netflight.com>; 'North American Network Operators' Group' <nanog@nanog.org> Subject: Re: Nat
I have a single CPE router and 3 /64's in use. One for each of the wireless SSID's and one for the wired network. This is the default for homenet devices. A single /64 means you >have to bridge all the traffic.
A single /64 has never been enough and it is time to grind that myth into the ground. ISP's that say a single /64 is enough are clueless.
Mark,
I agree that a /48 or /56 being reserved for business customers/sites is reasonable. But for residential use, I'm having a hard time believing multi-subnet home networks are even remotely common outside of networking folk such as the NANOG members. A lot of recent IPv4 devices such as smart TVs have the ability to auto-discover things they can talk to on the network. If we start segmenting our home networks to keep toasters from talking to thermostats, doesn't this end up meaning your average home user will need to be proficient in writing FW rules? Bridging an entire house network isn't that bad.
So *you* think the ISPs should *dictate* how a user internally splits up their network? There is NO technical reason to NOT give a customer multiple subnets. Every technology supports multiple prefixes. Even with 6rd you *can* give the user multiple subnets. It's only lazyness (or purchasing incompetence if the BR doesn't support multiple domains) that results in ISP's handing out single subnets over 6rd.
Chuck
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 12/17/15, 2:27 PM, "NANOG on behalf of Chuck Church" <nanog-bounces@nanog.org on behalf of chuckchurch@gmail.com> wrote:
-----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matthew Petach Sent: Thursday, December 17, 2015 1:59 PM Cc: North American Network Operators' Group <nanog@nanog.org> Subject: Re: Nat
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP.
And that recent thread on prefix delegation doesn't really leave a good taste in one's mouth about how to delegate a /56 or a /48 to a CPE, and get that/those prefix(s) in your (ISP) routing tables. Given that 99.999% of home users would be fine with a delegation of a single /64 and a single subnet I'm tempted to do that for now and let the DHCP-PD ink dry for a while so CPE support can follow up.
Which thread on which list? DHCP-PD works to any home gateway that supports IPv6. I know how the routing is set up in cable, don¹t know about other access. Or did you mean a prefix for a mobile device? Ongoing discussion in IETF v6ops, with consensus that multiple addresses are needed. There¹s disagreement among ISPs about what size prefix to delegate. So what? Pick a number and do it. I don¹t know of anybody who thinks a /64 is right for the home user, but I know of clueful people running every nibble between /60 and /48. Pick a number, plan so you can change it later, and deploy. Lee
Chuck
make ipv6 easier to deploy, especially in enterprise. repeat the previous sentence 42 times.
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of. Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
i disagree strongly on one point. ipv6 is about as far from pristine as a protocol can get. an icon of second system syndrome. and it is simpler than it used to be. remember TLAs, NLAs, ... but the dhcp st00pidity does encapsulate the arrogance and stupidity marvelously
what keeps the cows in the pasture is the quality of the grass not the height of the fence. Randy, I would happily appoint you as CIG-Q, the Chief Inspector of Grass Quality. ;)
i gave all such things up over 21 years ago randy
On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach" <nanog-bounces@nanog.org on behalf of mpetach@netflight.com> wrote:
On Wed, Dec 16, 2015 at 5:22 PM, Randy Bush <randy@psg.com> wrote:
We need to put some pain onto everyone that is IPv4 only.
this is the oppress the workers so they will revolt theory.
Ah, yes, the workers are quite revolting!
load of crap.
make ipv6 easier to deploy, especially in enterprise. repeat the previous sentence 42 times.
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
There¹s a mix of people at IETF, but more operator input there would be helpful. I have a particular draft in mind that is stuck between ³we¹d rather delay IPv6 than do it wrong² and ³be realistic about how people will deploy it." Lee
On Fri, Dec 18, 2015 at 04:20:48PM -0500, Lee Howard wrote:
On 12/17/15, 1:59 PM, Matthew Petach wrote:
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
All config is in one place. IP address, default gateway, domain name, DNS servers, search path, the lot. The mix of having to do this crazy thing of gateway announcements from one place, DNS from somewhere else, possibly auto-assigning addresses from a router, but maybe getting them over DHCPv6. It's just confusing and unnecessary and IMHO isn't helpful for persuading people to move to IPv6. Especially when everyone already understands DHCP in the v4 world. Both RAs and DHCP have their place and can be really useful together or apart in different situations, but witholding key functionality from DHCP "beacuse you can do it in a RA instead" isn't helping the v6 cause. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Matthew,
The mix of having to do this crazy thing of gateway announcements from one place, DNS from somewhere else, possibly auto-assigning addresses from a router, but maybe getting them over DHCPv6. It's just confusing and unnecessary and IMHO isn't helpful for persuading people to move to IPv6. Especially when everyone already understands DHCP in the v4 world.
Both RAs and DHCP have their place and can be really useful together or apart in different situations, but witholding key functionality from DHCP "beacuse you can do it in a RA instead" isn't helping the v6 cause.
Have you ever tried to deploy IPv6 (even if only in a lab environment)? I have worked with several companies (ISP and enterprise) and once they stop thinking "I want to do everything in IPv6 in exactly the same way as I have always done in IPv4" and actually look at the features that IPv6 provides them they are usually much happier with IPv6 than they were with IPv4. I am sure that a century ago people who were used to horse and buggy transport thought that cars were annoyingly complex and that having to put petrol in instead of hay was a huge problem. But I am very glad that in the end they adapted instead of convincing other people to make cars run on hay ;) Just joking of course, but seriously: we need to look at what the best solution for the future is, not at ways of avoiding having to learn something new/different. Cheers, Sander
Congratulations, Sander, on proving Matthew's point quite consicely. Matthew pointed out reasons that people don't like this setup, and reasons that they *AREN'T DEPLOYING IPV6*. And you blow them off with, "but it's not the best way." Great, I think I probably even agree with you that using the RAs is, in general better, but let me make this really clear. It. Is. An. Obstacle. For. Some. People. To. Deploy. IPv6. The IETF went for a lot of architectural purity (and ignored some real world valid use cases that RA just won't work for at all), and wanted something clean and well designed...and that's OK. But it doesn't help us solve the real-world problem of IPv4 depletion if that architectural purity causes people not to deploy the solution. Real world operators (some, at least) want default route/router assigned via DHCP for real world operational reasons. If the IETF and others respond merely by saying that it's better to do IPv6 this other way, right or wrong, *THE IETF* is the problem. It's far past time to worry about architectural purity. We need people deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this point, to fix the problems that are causing people not to deploy. On Sat, December 19, 2015 09:03, Sander Steffann wrote:
Hi Matthew,
The mix of having to do this crazy thing of gateway announcements from one place, DNS from somewhere else, possibly auto-assigning addresses from a router, but maybe getting them over DHCPv6. It's just confusing and unnecessary and IMHO isn't helpful for persuading people to move to IPv6. Especially when everyone already understands DHCP in the v4 world.
Both RAs and DHCP have their place and can be really useful together or apart in different situations, but witholding key functionality from DHCP "beacuse you can do it in a RA instead" isn't helping the v6 cause.
Have you ever tried to deploy IPv6 (even if only in a lab environment)? I have worked with several companies (ISP and enterprise) and once they stop thinking "I want to do everything in IPv6 in exactly the same way as I have always done in IPv4" and actually look at the features that IPv6 provides them they are usually much happier with IPv6 than they were with IPv4.
I am sure that a century ago people who were used to horse and buggy transport thought that cars were annoyingly complex and that having to put petrol in instead of hay was a huge problem. But I am very glad that in the end they adapted instead of convincing other people to make cars run on hay ;)
Just joking of course, but seriously: we need to look at what the best solution for the future is, not at ways of avoiding having to learn something new/different.
Cheers, Sander
-- Jeff
Hi Jeff,
It's far past time to worry about architectural purity. We need people deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this point, to fix the problems that are causing people not to deploy.
I partially agree with you. If people have learned how IPv6 works, deployed IPv6 (even if just in a lab) and came to the conclusion that there is an obstacle then I very much want to hear what problems they ran into. That's rarely the case unfortunately. Most of the time I hear "we don't want to learn something new". If the choice is between the IETF having to change standards vs some people having to learn something new then sorry, they will have to invest some time and learn.... IPv4 != IPv6. You have to keep learning, that's part of the job. Where we should focus our efforts is on making that learning process as easy as we can. That is an area where we have been failing horribly. Especially for enterprises. The mindset in enterprises is very different from that in ISPs, and we have been assuming for too long that documentation and best-practices for an ISP also work in an enterprise. I see a lot of enterprises that just don't know where to start, how to best run their networks with IPv6, with concerns about management, privacy, security etc. Changing standards isn't going to solve that (except to give them a false sense of security because it starts looking a lot like IPv4 on the surface). Besides: the time it takes to change standards and get new code deployed everywhere would be a bigger obstacle in getting IPv6 deployed soon anyway. So yes, people have to deploy IPv6 as soon as possible, but it's not the job of the IETF to fix all of the obstacles. There are definitely obstacles that the IETF needs to fix. But I don't think this is one of them... This one is better solved by showing how to make good use of all the nice features that IPv6 offers. Cheers, Sander
Sander Steffann wrote:
So yes, people have to deploy IPv6 as soon as possible, but it's not the job of the IETF to fix all of the obstacles.
What we need is for the IETF to stop being an obstacle. More to the point, as the IETF's opinion is based on the consensus of its working groups, it would help if specific people in a small number of IETF working groups stopped doing everything within their power to prevent dhcpv6 from becoming feature complete. Unfortunately, this turned into a religious war a long time ago and the primary consideration with regard to dhcpv6 has not been what's best for ipv6 or ipv6 users or ipv6 operators, but ensuring that dhcpv6 is sufficiently crippled as a protocol that it cannot be deployed without RA due to lack of features. It will happen, sooner or later. One of the large vendors is eventually going to make a corporate decision that the current situation is stupid and will come up with vendor specific extensions to dhcpv6 to make it a standalone protocol. Due to their size, everyone else will be forced to implement this standard. It's just a pity we can't set out and make a compatible standard on day 1, or even year 19. Nick
Hi Nick,
Unfortunately, this turned into a religious war a long time ago and the primary consideration with regard to dhcpv6 has not been what's best for ipv6 or ipv6 users or ipv6 operators, but ensuring that dhcpv6 is sufficiently crippled as a protocol that it cannot be deployed without RA due to lack of features.
As a network operator what I'm afraid of is the exact opposite: DHCP duplicating everything that RA does so that I now have duplicate and possibly conflicting sources of information. I already have to put DNS resolvers in both because some operating systems only use the ones provided in the RA and others only use those from DHCP. I can'd even begin to imagine the mess if e.g. routing information is also duplicated, with different operating systems using different sources. I don't really care about the solution itself. I don't mind the original situation where routing stuff is done in RA and the rest is done in DHCP. I wouldn't have minded if everything was in RA, or everything was in DHCP. But the worst choice would be conflicting or overlapping solutions with some people religiously only implementing one of them. There are always trade-offs. And some stupid design decisions were made in the past. But let's not create an even bigger mess... Cheers, Sander
I'm preparing some slides on this topic for an upcoming webinar our marketing team has roped me into :-) I'd love to hear from people on what they perceive and the real barriers they have seen with regards to IPv6 in your environment. I certainly have the list from our IT department. After much effort and under duress it seems they are making progress and 2016 will be the year it happens. Jared Mauch
On Dec 19, 2015, at 10:17 AM, Sander Steffann <sander@steffann.nl> wrote:
If the choice is between the IETF having to change standards vs some people having to learn something new then sorry, they will have to invest some time and learn.... IPv4 != IPv6. You have to keep learning, that's part of the job.
On Sat, Dec 19, 2015 at 7:17 AM, Sander Steffann <sander@steffann.nl> wrote:
Hi Jeff,
It's far past time to worry about architectural purity. We need people deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this point, to fix the problems that are causing people not to deploy.
I partially agree with you. If people have learned how IPv6 works, deployed IPv6 (even if just in a lab) and came to the conclusion that there is an obstacle then I very much want to hear what problems they ran into. That's rarely the case unfortunately. Most of the time I hear "we don't want to learn something new".
Hi Sander, I have multiple sets of clients on a particular subnet; the subnet is somewhat geographically distributed; I have multiple routers on the subnet. I currently am able to explicitly associate clients with the most appropriate router for them in v4. How can I do this using only RAs in IPv6? I'd be happy to learn something new. Unfortunately, my research hasn't shown me that there's something new to learn, it's shown me that "IPv6 can't do that, sorry." Thanks! Matt
Hi Matthew,
I have multiple sets of clients on a particular subnet; the subnet is somewhat geographically distributed; I have multiple routers on the subnet. I currently am able to explicitly associate clients with the most appropriate router for them in v4. How can I do this using only RAs in IPv6?
I'd be happy to learn something new. Unfortunately, my research hasn't shown me that there's something new to learn, it's shown me that "IPv6 can't do that, sorry."
Thanks for showing me a use-case that indeed doesn't work with IPv6 :) Cheers, Sander
On 12/19/2015 07:17 AM, Sander Steffann wrote:
Hi Jeff,
It's far past time to worry about architectural purity. We need people deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this point, to fix the problems that are causing people not to deploy.
I partially agree with you. If people have learned how IPv6 works, deployed IPv6 (even if just in a lab) and came to the conclusion that there is an obstacle then I very much want to hear what problems they ran into. That's rarely the case unfortunately. Most of the time I hear "we don't want to learn something new".
A) You don't need to deploy something to see that the design is overly complex, and not a good fit for existing, well-entrenched workflows. B) Many people have done this, and provided the exact feedback you describe, for well over a decade. There is no technical reason that IPv6 cannot have full-featured DHCP. The only obstacles are the purists like you who insist on the entire installed base coming up to speed with their cleverness. All the user education in the world will not fix that problem.
On 19 December 2015 at 15:49, Jeff McAdams <jeffm@iglou.com> wrote:
It's far past time to worry about architectural purity. We need people deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this point, to fix the problems that are causing people not to deploy.
If you want to deploy IPv6 NOW you will do it with the tools available NOW. There might be use cases with a real problem, but usually the problem is at layer 8/9. We had our share of difficulty with deploying IPv6, but the problems were in the implementations not the standards. I think it is naive to believe some people would deploy IPv6 if it was just a bit more like IPv4. No, they still would ignore it. Because the real reason was never anything to do with IPv6, but simply that they do not see any reason to do it. If these people wanted to do it, they would do it. Instead they make up excuses. You are wasting your time if you try to adapt to made up excuses. Regards, Baldur
Hi, On Sat, Dec 19, 2015 at 03:03:18PM +0100, Sander Steffann wrote:
The mix of having to do this crazy thing of gateway announcements from one place, DNS from somewhere else, possibly auto-assigning addresses from a router, but maybe getting them over DHCPv6. It's just confusing and unnecessary and IMHO isn't helpful for persuading people to move to IPv6. Especially when everyone already understands DHCP in the v4 world.
Have you ever tried to deploy IPv6 (even if only in a lab environment)? I have worked with several companies (ISP and enterprise) and once they stop thinking "I want to do everything in IPv6 in exactly the same way as I have always done in IPv4" and actually look at the features that IPv6 provides them they are usually much happier with IPv6 than they were with IPv4.
I've been running IPv6 for over 10 years. RAs and SLAAC. Doesn't affect my previous comment. :) IPv6 should by all means recommend certain technologies that are "better" in an idealogical world. Not having one small feature that makes it harder for people to deploy (for whatever the reason) does't help the cause. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
persuading people to move to IPv6. Especially when everyone already understands DHCP in the v4 world.
<snip>
enterprise) and once they stop thinking "I want to do everything in IPv6 in exactly the same way as I have always done in IPv4"
exactly. as my thoughts often gather at any IPv6 deployment event I go to "stop trying to shape IPv6 into your IPv4 model" yes, there are annoyances...like older routers/clients not supporting extensions to allow DNS/NTP etc from being fed in SLAAC...and clients only supporting SLAAC and not DHCPv6 etc etc but if you just SLAAC/DHCPv6 into your dual-stack environment then silly clients still get things via DHCPv4....and you start getting IPv6 connectivity...and then work through the NEXT part. more effort should be spent on eg address management and network topology. the client stuff is easy THEN we get to the stuff we should be looking at and expending more effort on... not 'how do I deploy IPv6?' but 'how do i switch off IPv4?' ;-) hopefully 2016 will be the year when more sites have IPv6-only networks on their enterprise networks with eg 464XLAT etc alan
On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee@asgard.org> wrote:
On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
Apologies for the delay in replying, work has been insanely busy as we come to the end of the quarter. The problem is when you have multiple routers in a common arena, there's no way to associate a given client with a given router unless the DHCP server can give out that information. In an enterprise wireless environment, you have many different subnets for different sets of employees. Unfortunately, the reality of common RF spectrum dictates you can't do separate SSIDs for every subnet your employees belong to; so, you have one SSID for the company that employees associate with, and then the DHCP server issues an appropriate IP to the laptop based on the certificate/credentials presented. In the v4 world, you get your IP address and your router information all from the DHCP server, you end up on the right subnet in the right building for your job classification, and all is good. In the v6 world, your DHCP server hands you an IP address, but the client sees an entire spectrum of routers to choose from, with no idea of which one would be most appropriate to make use of. Do I use the one that's here in the same building as me, or do I use one that's several blocks away in an entirely different part of the campus? The wonderful thing about modern wireless setups for enterprises is that you can allow your employees to all have their laptops configured to associate with the same SSID, and handle all the issues of assigning them to a particular subnet and vlan at the RADIUS/DHCPv4 level; you don't have to have different employees on different SSIDs for finance vs engineering vs HR vs sales. In v4, you can segment the employees very nicely after they've associated with the AP and give them all the necessary information for building in which they're in. V6 doesn't provide that ability; so, I associate with the AP, I get my IPv6 address, and then I look at which possible routers are announcing information about my subnet, and I see there's one in building B, one in building F, and one in building W, and I just randomly pick one, which may be nearby, or may be across the other side of campus. Furthermore, I also see all the announcements from routers for subnets I'm *not* a part of, cluttering up the spectrum. Rather than have routers spewing out "here I am" messages and taking up RF spectrum, I'd much prefer to explicitly tell clients "you're in sales, you're in building W, here's your IP address, and use the upstream router located in your building." No extra RF spectrum used up by routers all over the place saying "here I am", no issues of clients choosing a less-optimal upstream router and then complaining about latency and performance. I can see where in some environments, routers using RAs to announce their presence to clients makes sense. Large-scale enterprise wireless isn't one of those; so, give us the *ability* to choose to explicitly give out router information via DHCPv6 in those situations. I'm not saying RAs are bad; I'm simply saying that the IETF plugging its ears to the needs of enterprises and claiming that we just don't 'get' how IPv6 is supposed to work and therefore they won't support assigning router information via DHCPv6 is an impediment to more rapid adoption. And for those of you who say "but just use different SSIDs for every subnet in the company", please go do some reading on how SSIDs are beaconed, and what the effective limit is on how many SSIDs you can have within a given region of RF coverage. It's generally best to keep your SSID count in the single digits; by the time you get more than a dozen SSIDs, you're using up nearly half of your RF spectrum just beaconing the SSIDs.
Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
There¹s a mix of people at IETF, but more operator input there would be helpful. I have a particular draft in mind that is stuck between ³we¹d rather delay IPv6 than do it wrong² and ³be realistic about how people will deploy it."
Lee
I agree more operator input would be good; unfortunately, it's easier for management to say "let's just delay IPv6 until they get it working" than it is to justify sending employees to IETF meetings all over the place to explain why their model of how IPv6 should work isn't working out for the enterprise. In effect, the IETF's stance is making it more expensive for companies to deploy IPv6 than simply stay on IPv4--so is it any wonder that people aren't moving faster? Reduce the friction preventing companies from being able to do parallel, homologous IPv6 deployments, and you'll see faster movements. Right now, the insistence that IPv6 *must* be done differently, and *must* be done with an orthogonal network design and topology is an increased cost companies are unwilling to bear. And there is *NO* technical reason that DHCPv6 could not be allowed to provide identical information as DHCPv4; it is purely human stubbornness on the part of IETF members who insist that *their* model of how IPv6 should be deployed is better, and therefore they won't even allow the *option* to do it a different way. Such hubris! Is it any wonder people avoid dealing with the IETF? OK. Taking some deep breaths and calming back down now... Fundamentally, Lee, the challenge is when you have multiple routers for a given subnet, how do you put some set of clients pointing to one router, and a different set of clients pointing to another router using RAs? Thanks! Matt
This is OT of NAT, but follows the existing discussion. Since discussion has warped around to host configuration DHCP (again), it might be useful to review discussions dating from 2011: The stupidity of trying to "fix” DHCPv6 and The Business Wisdom of trying to "fix” DHCPv6 which also refer to discussions from 2009. The pertinent Business View is
The security domain for HOST should not overlap the security domain for ROUTER.
That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP! It is imperative to supply the features that End System Operators find useful for their business. This simple position is independent of IPv4/IPv6 differences.
Since DHCP is a Host Configuration tool and is quite independent of router configurations except for DHCP forwarding entries, we must quit requiring ongoing fiddly network router configuration changes to make End System configuration changes. These can be centrally managed by DHCP run to meet End System configuration requirement, even including providing default routes. This simple position is independent of IPv4/IPv6 differences. All that is necessary is for us to end the years of religious debate of DHCP vs RA and to start providing solutions that meet business management needs. James R. Cutler James.cutler@consultant.com PGP keys at http://pgp.mit.edu
On Dec 19, 2015, at 1:01 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Fri, Dec 18, 2015 at 1:20 PM, Lee Howard <Lee@asgard.org> wrote:
On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
Apologies for the delay in replying, work has been insanely busy as we come to the end of the quarter.
The problem is when you have multiple routers in a common arena, there's no way to associate a given client with a given router unless the DHCP server can give out that information.
In an enterprise wireless environment, you have many different subnets for different sets of employees. Unfortunately, the reality of common RF spectrum dictates you can't do separate SSIDs for every subnet your employees belong to; so, you have one SSID for the company that employees associate with, and then the DHCP server issues an appropriate IP to the laptop based on the certificate/credentials presented. In the v4 world, you get your IP address and your router information all from the DHCP server, you end up on the right subnet in the right building for your job classification, and all is good. In the v6 world, your DHCP server hands you an IP address, but the client sees an entire spectrum of routers to choose from, with no idea of which one would be most appropriate to make use of. Do I use the one that's here in the same building as me, or do I use one that's several blocks away in an entirely different part of the campus?
The wonderful thing about modern wireless setups for enterprises is that you can allow your employees to all have their laptops configured to associate with the same SSID, and handle all the issues of assigning them to a particular subnet and vlan at the RADIUS/DHCPv4 level; you don't have to have different employees on different SSIDs for finance vs engineering vs HR vs sales. In v4, you can segment the employees very nicely after they've associated with the AP and give them all the necessary information for building in which they're in. V6 doesn't provide that ability; so, I associate with the AP, I get my IPv6 address, and then I look at which possible routers are announcing information about my subnet, and I see there's one in building B, one in building F, and one in building W, and I just randomly pick one, which may be nearby, or may be across the other side of campus. Furthermore, I also see all the announcements from routers for subnets I'm *not* a part of, cluttering up the spectrum. Rather than have routers spewing out "here I am" messages and taking up RF spectrum, I'd much prefer to explicitly tell clients "you're in sales, you're in building W, here's your IP address, and use the upstream router located in your building." No extra RF spectrum used up by routers all over the place saying "here I am", no issues of clients choosing a less-optimal upstream router and then complaining about latency and performance.
I can see where in some environments, routers using RAs to announce their presence to clients makes sense. Large-scale enterprise wireless isn't one of those; so, give us the *ability* to choose to explicitly give out router information via DHCPv6 in those situations. I'm not saying RAs are bad; I'm simply saying that the IETF plugging its ears to the needs of enterprises and claiming that we just don't 'get' how IPv6 is supposed to work and therefore they won't support assigning router information via DHCPv6 is an impediment to more rapid adoption.
And for those of you who say "but just use different SSIDs for every subnet in the company", please go do some reading on how SSIDs are beaconed, and what the effective limit is on how many SSIDs you can have within a given region of RF coverage. It's generally best to keep your SSID count in the single digits; by the time you get more than a dozen SSIDs, you're using up nearly half of your RF spectrum just beaconing the SSIDs.
Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
There¹s a mix of people at IETF, but more operator input there would be helpful. I have a particular draft in mind that is stuck between ³we¹d rather delay IPv6 than do it wrong² and ³be realistic about how people will deploy it."
Lee
I agree more operator input would be good; unfortunately, it's easier for management to say "let's just delay IPv6 until they get it working" than it is to justify sending employees to IETF meetings all over the place to explain why their model of how IPv6 should work isn't working out for the enterprise.
In effect, the IETF's stance is making it more expensive for companies to deploy IPv6 than simply stay on IPv4--so is it any wonder that people aren't moving faster?
Reduce the friction preventing companies from being able to do parallel, homologous IPv6 deployments, and you'll see faster movements. Right now, the insistence that IPv6 *must* be done differently, and *must* be done with an orthogonal network design and topology is an increased cost companies are unwilling to bear. And there is *NO* technical reason that DHCPv6 could not be allowed to provide identical information as DHCPv4; it is purely human stubbornness on the part of IETF members who insist that *their* model of how IPv6 should be deployed is better, and therefore they won't even allow the *option* to do it a different way.
Such hubris! Is it any wonder people avoid dealing with the IETF?
OK. Taking some deep breaths and calming back down now...
Fundamentally, Lee, the challenge is when you have multiple routers for a given subnet, how do you put some set of clients pointing to one router, and a different set of clients pointing to another router using RAs?
Thanks!
Matt
On 12/18/2015 01:20 PM, Lee Howard wrote:
On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
C'mon Lee, stop pretending that you're interested in the answer to this question, and wasting everyone's time in the process. You know the answers, just as well as the people who would give them.
Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
There¹s a mix of people at IETF, but more operator input there would be helpful. I have a particular draft in mind that is stuck between ³we¹d rather delay IPv6 than do it wrong² and ³be realistic about how people will deploy it."
On this topic the operator input has been clear for over a decade, and yet the purists have blocked progress this whole time. The biggest roadblock to IPv6 deployment are its most ardent "supporters."
On 1/7/16, 7:39 PM, "NANOG on behalf of Doug Barton" <nanog-bounces@nanog.org on behalf of dougb@dougbarton.us> wrote:
On 12/18/2015 01:20 PM, Lee Howard wrote:
On 12/17/15, 1:59 PM, "NANOG on behalf of Matthew Petach"
I'm still waiting for the IETF to come around to allowing feature parity between IPv4 and IPv6 when it comes to DHCP. The stance of not allowing the DHCP server to assign a default gateway to the host in IPv6 is a big stumbling point for at least one large enterprise I'm aware of.
Tell me again why you want this, and not routing information from the router?
C'mon Lee, stop pretending that you're interested in the answer to this question, and wasting everyone's time in the process. You know the answers, just as well as the people who would give them.
I’m flattered that you think I know so much. Jared gave a useful reply, and I’m doing research before writing an internet-draft.
Right now, the biggest obstacle to IPv6 deployment seems to be the ivory-tower types in the IETF that want to keep it pristine, vs allowing it to work in the real world.
There¹s a mix of people at IETF, but more operator input there would be helpful. I have a particular draft in mind that is stuck between ³we¹d rather delay IPv6 than do it wrong² and ³be realistic about how people will deploy it."
On this topic the operator input has been clear for over a decade, and yet the purists have blocked progress this whole time. The biggest roadblock to IPv6 deployment are its most ardent "supporters."
I don’t think IPv6 evangelists are in the way. I do think many enterprises don’t care about IPv6, and no protocol changes will make a difference. Some enterprise administrators wouldn’t mind deploying IPv6 as long as they don’t have to think about it. I think this is foolish: deploying a new Internet Protocol will not be simpler than deploying a new Spanning Tree or a new routing protocol. There are also enterprise administrators who have technical concerns; those are the ones I want to help. Lee
hi folkx On 12/17/15 at 10:28am, Mark Andrews wrote:
We need to make IPv4 painful to use.
already is too crowded
Adding delay between SYN and SYN/ACK would be one way to achieve this.
<flame suiton> change tcp windoow size to 1 byte per packet or decrease from 1500 byte packets, more traffic they use, slower it becomes instead of zero byte as used in tarpits
Start at 100ms..200ms and increase it by 100ms each year.
some of verizon's shared IPv4 traffic has delays exceeding 3sec and i seen it exceeding 6sec for simple things like using gmail thru their network "delays" are built in automatically ... - too much spam .. - too much useless video downloads - too much useless steaming - too much useless pix - too much games and alll that junk will increase as more people use it it'd be nice to put these "services" on their own private LAN and slow just themself down instead of slowing everybody down pay more $$$ to get better/faster connectivity ... </flame suiton> ducking for cover alvin
On 12/16/2015 17:28, Mark Andrews wrote:
+1000000
Nobody should have to be doing NAT today.
We need to make IPv4 painful to use. Adding delay between SYN and SYN/ACK would be one way to achieve this. Start at 100ms..200ms and increase it by 100ms each year.
If it is such a good idea, why do you have to do that? -- sed quis custodiet ipsos custodes? (Juvenal)
participants (38)
-
'Matt Palmer' -
A.L.M.Buxey＠lboro.ac.uk -
Ahmed Munaf -
alvin nanog -
Baldur Norddahl -
Berry Mobley -
Charles Monson -
Chuck Church -
Daniel Corbe -
Doug Barton -
Hunter Fuller -
James R Cutler -
Jared Mauch -
Jason Baugher -
Jeff McAdams -
Jon Lewis -
Josh Reynolds -
Keith Medcalf -
Larry Sheldon -
Lee Howard -
Livingood, Jason -
Mark Andrews -
Mark Tinka -
Matt Palmer
-
Matthew Newton -
Matthew Petach -
Mel Beckman -
Mike Hammett -
Netideainc -
Nick Ellermann -
Nick Hilliard -
Octavio Alvarez -
Owen DeLong -
Randy Bush -
Randy Fischer -
Sander Steffann -
Stephen Satchell -
Tony Wicks