RE: Request To Advance : "Unique Local IPv6 Unicast Addresses"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Request To Advance : "Unique Local IPv6 Unicast Addresses"
"Jeroen Massar" <jeroen@unfix.org> wrote:
|Dan Lanciani wrote:
|
|> "Jeroen Massar" <jeroen@unfix.org> wrote:
|>
|> |I have only one note on the "unique local ipv6 address" subject:
|> |
|> |Organisations wanting "unconnected addressspace" should go to
|> |an existing organisation that they think will outlast them in age
|> |and that already has a LIR allocation allocated. Give them some
|> |money to make them happy and request a /48 from them.
|<SNIP>
|
|> I'm sure that some ISP could see business in this. What I
|> don't understand is why it is necessary or desirable to create a revenue
|> stream for ISPs in this way. Could you explain how it is beneficial to the v6
|> user community add an artificial address rental cost to internal
|> networking operations?
|
|I never said that it would be benificial to the user community,
Then why do it?
|But it is one solution that can be taken *now* by the (many?) companies
|that require this scenario.
You appear to be suggesting it as an alternative to the proposed permanent
allocations which this thread is about. In that context it has been proposed
before. I do not believe that it is a good reason to delay (or worse, reject)
the current proposal for permanent allocations.
|The 'pay some money' in the scenario above could also be replaced
|by 'rub his back' or 'donate a keg of beer' which makes many ISP's
|happy already. One could also request a /48 from one of the many
|Tunnel Broker systems out there and just don't use it globally ;)
Why have this uncertainty in cost (and even in availability) when we can
have simple, permanent allocations as proposed?
Dan Lanciani
ddl@danlan.*com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.