Fixed Boundary (/29) Assignments

The answer to this slides is quick and easy:

The justification for the demand is wrong, so the demand has to be denied.


Those type of access noted in the slides should be (from the implementations
point of view) possible with private/NAT IP space, too.  Thus you cannot
justify a possible future IP demand with a false implementation of services.
There might be other justifications, but widely deployed Internet TV and
VoIP which is designed to need non-private IP space at the customers side is
the proof for that something is wrong with the implementation of Internet TV
and VoIP.  This is simply a mathematical fact as there are less IPs (4
Billion) than possible customers (5 Billion, and for VoIP plus Internet-TV
you then need 10 Billion IPs).


Here the full story:

a) Internet TV.  I can get video streams with my NATted IPs without *any*
problem.

The only thing to give Internet TV watchers a non-private IP is for
marketing, to identify the consumer.  Thus alone from the privacy side of
view this demand has to be declined.  As the customers don't have the
knowledge themself somebody should take care of it.  And I have no problems
with this if RIPE protects the innocent ;)


b) VoIP.  VoIP needs an assigned IP if you want to be called.  This can be
regarded as a bug in the standard.  It definitively should be possible to do
VoIP over NATted lines *with* the possibility to receive a call, too!

Thus, from an administrative point of view of people who are responsible for
the security of corporate networks, there should be a way to hide the
complete corporate behind a VoIP gateway and make it possible to route this
service directly into the telephony gateway.  To be usable the service must
be able to distinct between different endpoints without need to consult a
directory.  A second thing is that VoIP has a privacy problem, because you
can decode the VoIP packets without problems if you have access to the right
internet node (router).  Thus there is really nothing wrong with such VoIP
gateways who concentrate such connections, there is something seriously
wrong with VoIP and nobody should point to things like IPsec, because it
takes decades until it is deployed in a usable fashion.

Same holds for Service Providers or ISPs.  They should provide the VoIP
gateway option to their customers, such that the customer does not need
non-private IPs for VoIP.

Thus I vote again for denying such a possible future demand.  We should not
do "proposed allocations on existing bugs".  And this way you will see the
correct implementations to do Internet TV and VoIP will spring in existence
very quickly by demand, such that NAT users can start to use them, too.

Besides:  Yes, this renders the Microsoft implementation "Net2Phone" as
unusable as it should be.  It's rediculous not even to consider Proxies or
NAT-Gateways.  And no, you simply cannot do as described in the Net2Phone
doc as there just do not exist 100K ports in IP to hide a bigger corporate
network behind 1 IP.  And if you have to use more than 1 IP there is
something wrong with the service, as all newer services *have* to be
designed with IPv4 conservation in mind.


----- Original Message -----
From: "leo vegoda" <leo at ripe.net>
To: <lir-wg at ripe.net>
Sent: Friday, February 09, 2001 2:47 PM
Subject: Re: Fixed Boundary (/29) Assignments


> Hiya,
>
> On Wed, Feb 07, 2001 at 05:34:00PM -0700, in message
<Pine.GSO.4.21.0102071649210.7706-100000 at shell1.phx.gblx.net>, David R
Huberman (huberman at gblx.net) wrote: Re: Re: Fixed Boundary (/29) Assignments
>
> [...]
>
> > We are not discussing commercial broadband customers. The fixed-boundary
> > assignment 'proposal' is exclusively for residential broadband
customers.
>
> I get the impression that people have confused the requests we have
> received with a desire on our part to change the policy. The slide in
> question is <URL: http://www.ripe.int/ripe/wg/lir/present/sld003.html>.
>
> Can I quickly point out that RIPE NCC is not proposing a change to the
> policy - merely asking the Working Group to discuss the policy and decide
> what it ought to be.
>
> Many thanks,
>
> --
> leo vegoda
> RIPE NCC Bloke
>