-----Original Message----- From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] Sent: Thursday, July 31, 2003 12:16 PM To: Jeroen Massar Cc: nanog@merit.edu Subject: RE: North America not interested in IP V6
Jeroen Massar wrote: It has a timeline (slides 47-50) showing the US falling behind for at least 3 years... come on US show what you are good for :)
Show me where there is money to make with IPv6 first :-) There are some exceptions, but here v6 is somehow like ISDN: I Still Don't Need.
Michel.
Christian Huitema of Microsoft presented on IPv6 at our Catalyst conference last month. He noted that Microsoft had a very difficult time creating xBox live due to issues with IPv4/NAT, which is one of the reasons they are pushing for IPv6 as the basis for future collaborative/peer-to-peer applications (for example, 3degrees). I believe Sony is also IPv6 enabling their products for the same reason. For these services to truly scale you've got be able to have true peer-to-peer computing. Right now, I'm not able to directly connect to my neighbor's computer to play a game if we are both on home LANs. I'm not able to directly connect to my PC at home when I'm on the road. I can't accept incoming phone calls to my netmeeting client without static configuration of my NAT gateway (same for an IP softphone). It would be a configuration nightmare to get four Vonage phones each with their own phone number. Christian provided a wonderful demonstration of a future interactive video application that would be difficult to scale if proxy/NAT services got in the way. There are lots of things that just don't work, and lots of opportunities for making money with IPv6. My own personal opinion is that over the next 5-10 year everything will come out of the box with IPv6 capabilities, making it fairly straightforward to turn on. I doubt we'll see much acceptance in the enterprise space before then, but there are significant opportunities to bring additional services into the home and serve those on home networks if we can eliminate NAT. As one person noted in response to Christian's speech. If there is no addressing shortage, why do I have to pay $75 a month for a DSL connection with a static IP address when a floating IP address only costs me $40 per month? Just my .02c irwin
On Thu, Jul 31, 2003 at 11:02:14AM -0600, Irwin Lazar quacked:
As one person noted in response to Christian's speech. If there is no addressing shortage, why do I have to pay $75 a month for a DSL connection with a static IP address when a floating IP address only costs me $40 per month?
I think there are two parts to the answer. a) DHCP'ing everyone is just easier. b) Why do you pay less for a flight with a saturday night stopover? - Market segmentation. People with static addresses usually want to do things like run servers, and are probably willing to pay for the privilege. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
David G. Andersen wrote:
b) Why do you pay less for a flight with a saturday night stopover? - Market segmentation. People with static addresses usually want to do things like run servers, and are probably willing to pay for the privilege.
And by paying for it, they subsidize the bandwidth used by others. Do people really think 1.5Mb/s is only $40/mo? Ha! -Jack
DGA> Date: Thu, 31 Jul 2003 13:10:20 -0400 DGA> From: David G. Andersen DGA> a) DHCP'ing everyone is just easier. Assign unchanging IP address based on MAC address. Done/done. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
DGA> Date: Thu, 31 Jul 2003 13:10:20 -0400 DGA> From: David G. Andersen
DGA> a) DHCP'ing everyone is just easier.
Assign unchanging IP address based on MAC address. Done/done.
And quadrupple your techsupport costs? Thanks, but no thanks. Alex
[E.B. Dreger writes]
Assign unchanging IP address based on MAC address. Done/done.
* alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 20:28 CEST]:
And quadrupple your techsupport costs? Thanks, but no thanks.
For always assigning the same IP address to a customer? Why would this increase support costs? customer: "I keep getting the same IP address if I click on release/renew!" support: "Yes, that's how it's supposed to work with our systems." customer: "Oh, ok *click*" -- Niels.
On Sat, 2 Aug 2003, Niels Bakker wrote:
[E.B. Dreger writes]
Assign unchanging IP address based on MAC address. Done/done.
* alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 20:28 CEST]:
And quadrupple your techsupport costs? Thanks, but no thanks.
For always assigning the same IP address to a customer? Why would this increase support costs?
especially done via dhcp... you could probably even automate getting new ips from a dynamic pool and slapping them into permanent assignments.
On Sat, Aug 02, 2003 at 07:10:38PM +0000, Christopher L. Morrow wrote:
On Sat, 2 Aug 2003, Niels Bakker wrote:
[E.B. Dreger writes]
Assign unchanging IP address based on MAC address. Done/done.
* alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 20:28 CEST]:
And quadrupple your techsupport costs? Thanks, but no thanks.
For always assigning the same IP address to a customer? Why would this increase support costs?
especially done via dhcp... you could probably even automate getting new ips from a dynamic pool and slapping them into permanent assignments.
And when the customer slaps in a replacement NIC (recall that with wintel NICs the MAC is carried with the card) and he can't get his old address back, do you expect to convince all your customers that's ok, or train your support folks to go into your DHCP config database and reassign the "permanent" assignment? Or do you setup a web-based reg system whereby the customer must connect and get the address reassigned? How little support do you think any of those options will require? Who was it that said, "if you can't identify at least 3 new problems introduced by any solution, you don't understand the situation?" -- Ray Wong rayw@rayw.net
[E.B. Dreger writes]
Assign unchanging IP address based on MAC address. Done/done.
* alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 20:28 CEST]:
And quadrupple your techsupport costs? Thanks, but no thanks.
[Niels Bakker writes]
For always assigning the same IP address to a customer? Why would this increase support costs?
[Christopher L. Morrow writes]
especially done via dhcp... you could probably even automate getting new ips from a dynamic pool and slapping them into permanent assignments.
* rayw@rayw.net (Ray Wong) [Sat 02 Aug 2003, 21:29 CEST]:
And when the customer slaps in a replacement NIC (recall that with wintel NICs the MAC is carried with the card) and he can't get his old address back, do you expect to convince all your customers that's ok, or train your support folks to go into your DHCP config database and reassign the "permanent" assignment? Or do you setup a web-based reg system whereby the customer must connect and get the address reassigned? How little support do you think any of those options will require?
That's one way of doing it; a large cable ISP in the Netherlands required customers to phone in when they had fried their network card. Nowadays the cable modems handed out to subscribers allow configuration of this by the end customer. BUT: I don't think Chris and me were thinking about big bad ugly LANs with customers attached indiscriminately, though. With DSL provisioning systmes using RFC1483 bridged (do I have my buzzwords correct here?) the DHCP server can discriminate between customers based on VCI/VPI numbers instead, negating the need to look at the MAC address of the request.
Who was it that said, "if you can't identify at least 3 new problems introduced by any solution, you don't understand the situation?"
Or you don't understand ours. After all, it's currently all getting done already this way. -- Niels (who thinks IPv6 Router Advertisements are broken when hosts are multihomed)
On Sat, Aug 02, 2003 at 09:43:45PM +0200, Niels Bakker wrote:
Assign unchanging IP address based on MAC address. Done/done.
BUT: I don't think Chris and me were thinking about big bad ugly LANs with customers attached indiscriminately, though. With DSL provisioning systmes using RFC1483 bridged (do I have my buzzwords correct here?) the
Correct RFC, close enough.
DHCP server can discriminate between customers based on VCI/VPI numbers instead, negating the need to look at the MAC address of the request.
Note the exlusive conditions presented by the position you defend and your own. The point being, relying on MAC address is a problematic idea. Yes, you could configure an address based on the PVC; Redbacks even like being configured that way. BTDT. There are still any number of situations whereby you will get grumpy customers loading up your support lines with "problems."
Who was it that said, "if you can't identify at least 3 new problems introduced by any solution, you don't understand the situation?"
Or you don't understand ours. After all, it's currently all getting done already this way.
The question is of specific versus general cases. Not seeing the drawbacks because you can cite a place where something is successful does not solve the problem for everyone else. In reality, this is not a technical problem, hence there is no way to win. -- Ray Wong rayw@rayw.net
Who was it that said, "if you can't identify at least 3 new problems introduced by any solution, you don't understand the situation?" Or you don't understand ours. After all, it's currently all getting done already this way. The question is of specific versus general cases. Not seeing the drawbacks because you can cite a place where something is successful does not solve the problem for everyone else.
I don't find a solution that requires customers to place phone calls to have some number changed somewhere acceptable either. Therefore it doesn't really apply. Just like DHCP won't work for dialup users (yeah, let's all configure L2TP tunnels over dialup and run DHCP over that! It'd suck, same point, different reasoning, not an applicable solution either.) (On a tangent about having to make phone calls after hardware changes, I was pretty surprised when a friend had to do that after she had received a replacement mobile phone after her previous had been stolen. In Europe, you get a new SIM card from the telco and a new phone from your insurance company, no additional trickery is needed.)
In reality, this is not a technical problem, hence there is no way to win.
Wisely spoken. Regards, -- Niels.
That's one way of doing it; a large cable ISP in the Netherlands required customers to phone in when they had fried their network card. Nowadays the cable modems handed out to subscribers allow configuration of this by the end customer.
BUT: I don't think Chris and me were thinking about big bad ugly LANs with customers attached indiscriminately, though. With DSL provisioning systmes using RFC1483 bridged (do I have my buzzwords correct here?) the DHCP server can discriminate between customers based on VCI/VPI numbers instead, negating the need to look at the MAC address of the request.
When you dont have alternatives, it does seem like a possible good idea. When it costs money to add additional customers, any additional step that a customer should make gives the customer yet another reason to switch to someone that does not make them jump. Alex
On Sat, 2 Aug 2003, Niels Bakker wrote:
[E.B. Dreger writes]
Assign unchanging IP address based on MAC address. Done/done.
* alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 20:28 CEST]:
And quadrupple your techsupport costs? Thanks, but no thanks.
For always assigning the same IP address to a customer? Why would this increase support costs?
especially done via dhcp... you could probably even automate getting new ips from a dynamic pool and slapping them into permanent assignments.
Rubbish. If you do that, you lose all the benefits. Also, when a customer's son/daugter/computer-expert-from-chubb-institute-friend does something and it breaks your lovely system you will not just increase your tech support costs, but also will lose the customer. Alex
[E.B. Dreger writes]
Assign unchanging IP address based on MAC address. Done/done.
* alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 20:28 CEST]:
And quadrupple your techsupport costs? Thanks, but no thanks.
For always assigning the same IP address to a customer? Why would this increase support costs?
customer: "I keep getting the same IP address if I click on release/renew!" support: "Yes, that's how it's supposed to work with our systems." customer: "Oh, ok *click*"
"My internet no longer works." "Did you blah?" "I do not know" "Did you blah blah?" "I do not know" "Did you blah blah blah" "Dont you understand? It just does not work. I am going to Verizon. I am canceling my account" Alex
Alex, * alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 22:19 CEST]:
"My internet no longer works." "Did you blah?" "I do not know" "Did you blah blah?" "I do not know" "Did you blah blah blah" "Dont you understand? It just does not work. I am going to Verizon. I am canceling my account"
`Your' Internet not working is completely orthogonal to my use of DHCP. Kindest regards, -- Niels.
`Your' Internet not working is completely orthogonal to my use of DHCP.
What happens to the previous address? Does it get returned to the cusotmer after his/hers DNS stops working? He does not know that the "Static" address that the provider is advertising is as static as the piece of hardware that connects him/her to the provider. Remember, the vast majority of people, including those who happen work in some levels of this industry, dont know what a MAC address is etc. At what point the automated system will smell something as fishy? Would that happen if it sees ten different MAC addresses within a day? Two days? Three days? There is a higher cost to provide the static address service. Giving it for free makes no sense. There is a much smaller cost to provide dynamic address service, which tends to be built into the provice of the product. Alex
Alex, * alex@yuriev.com (alex@yuriev.com) [Sat 02 Aug 2003, 22:43 CEST]:
What happens to the previous address? Does it get returned to the cusotmer after his/hers DNS stops working? He does not know that the "Static" address that the provider is advertising is as static as the piece of hardware that connects him/her to the provider. Remember, the vast majority of people, including those who happen work in some levels of this industry, dont know what a MAC address is etc.
I have already stated in another mail that the situation you describe above is indeed undesirable, and in such an environment the use of DHCP may not be recommendable if business continuity is deserved. I'd prefer not to continue to harp on this subject any further as I consider us (you, me, Chris Marrow, others) in agreement on it.
There is a higher cost to provide the static address service. Giving it for free makes no sense. There is a much smaller cost to provide dynamic address service, which tends to be built into the provice of the product.
-- Niels.
participants (8)
-
alex＠yuriev.com -
Christopher L. Morrow -
David G. Andersen -
E.B. Dreger -
Irwin Lazar -
Jack Bates -
Niels Bakker -
Ray Wong