extending at the edge

[Eric Vyncke (evyncke)]

Lorenzo,

I am sad to write that you are right...

NAPT for IPv6 exists, at least two vendors implement it... Including my employer, I do not like it but I want to get my salary paid OTOH :-) And, BTW, this was based on customers' request :-( As you wrote, people want to redo their IPv4 'bad designs' in IPv6...

Even worse, they also want to renew the IPv6 prefix every now and then as they did for IPv4 causing renumbering.

Now, from my experience, when talking to SP, they are not stupid and their architects understand the future of Internet but it burns your time if we, as a community, have to talk 1:1 to each SP on the planet...

-éric

From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Lorenzo Colitti
Sent: jeudi 11 octobre 2012 07:06
To: Simon Lockhart
Cc: Tony Finch; ipv6-ops at lists.cluenet.de; Gert Doering; Nick Hilliard
Subject: Re: extending at the edge

On Thu, Oct 11, 2012 at 12:27 AM, Simon Lockhart <simon at slimey.org<mailto:simon at slimey.org>> wrote:
> Right. I was thinking of hotel or cafe hot spots - where you are likely to
> want to sign up once and share rather than sign up multiple devices
> separately.
But surely the provider is going to *want* you to sign up multiple times -
particularly if it's a pay-for service. They're not going to want you to pay once, then share it to all your mates, as that's loss of revenue.

There's not really much providers can do to stop it, just like they can't stop IPv4 connection sharing via NAT today. Sure, they can restrict one MAC address to one /128 (ignoring the fact that this breaks privacy addresses), but even if they do that, then the wifi hotspot vendors will implement IPv6 NAPT (not currently defined by the IETF, but that's certainly not going to stop anyone).

Once that happens, everybody has lost:

  *   The provider has implemented complex functionality which a) doesn't prevent the revenue loss they wanted to prevent, and b) increases operational and support costs.
  *   The user loses end-to-end connectivity and the capability to uniquely address his devices.
  *   The application developers pay the price of working around the NAPT complexity.
  *   The vendors and consultants... well, OK - maybe they benefit :-)
Unfortunately, past experience suggests that fact that providers can't stop it is unlikely to stop them from trying. I don't see a good way around this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20121011/66b45090/attachment.htm>