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
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
Date: Thu, 31 Jul 2003 13:10:20 -0400
From: David G. Andersen
a) DHCP'ing everyone is just easier.
Assign unchanging IP address based on MAC address. Done/done.
Eddy
> Date: Thu, 31 Jul 2003 13:10:20 -0400
> From: David G. Andersen
> 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.
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?"
[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)
>>>>> 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.
[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
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
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
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.
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.
`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.