Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

[Alexandru Petrescu <[e-mail]>]

Le 16/02/2014 20:51, Owen DeLong a écrit :
>
> On Feb 16, 2014, at 10:34 , Alexandru Petrescu
> <[e-mail]> wrote:
>
>> Le 16/02/2014 19:22, Owen DeLong a écrit :
>>>
>>> On Feb 16, 2014, at 06:41 , Alexandru Petrescu
>>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> Le 15/02/2014 19:16, Owen DeLong a écrit :
>>>>> Indeed, the situations where ULA usage is detrimental vastly
>>>>>  outnumbers those where it is actually beneficial.
>>>>>
>>>>> If we're going to move something like this forward, that
>>>>> really should be made clear.
>>>>
>>>> Consider new deployments like IPv6 vehicular networks.
>>>>
>>>> There is an immediate direction to demonstrate an IPv6 vehicle
>>>> if it used ULA.  There is also the alternative to request PI
>>>> or PA IPv6 addressing space for these vehicles from some
>>>> registry, steps which may take time.
>>>>
>>>
>>> It takes about 48 hours to get address space approved from a
>>> registry. Even less time to get some from a provider in most
>>> cases.
>>
>> Is that for free and does it include setting up IPv6 routing to
>> it, in Europe?
>
>> From the RIR, you would have to pay RIR fees. From an ISP, you
>> probably get it for free, yes.

A-ha.

But the ISP is this cellular operator.  How long would it take me to
persuade a cellular operator (which is not related to a vehicle
manufacturer) to obtain so much address space as to give more than one
/64 to a vehicle?  And then to persuade all cellular operators in a
certain country to do the same for all other vehicle?

Talking to cellular operators I hear often this need to not give more 
than one 64 because of billing, and because of augmented security risks.

> No. However, since you _CAN'T_ set up routing to ULA, I'm not sure
> how that applies.

In a sense yes and in another no.

Certainly a ULA prefix unique per vehicle would not allow to set routing
to them.  (neither would it if that were a PI space).

But a ULA in the vehicle in same space as a ULA in a separate
infrastructure (not operator's), would allow to set up tunnelling, and 
query the services offered by that infrastructure.  And yes, that would 
work with a PI space as well (instead of ULA).

Also, a translating mechanism in the vehicle (from ULA prefix to the /64
publicly routable provided by the operator) would allow for this to 
work.  This address translating mechanism may take various forms such as 
IPv6 NAT, NPT, and others which would allow network-layer reverse 
reachability.  I am not proposing this mechanism here, but it would rely 
on the easiness to make up ULAs.

>>> I do not at all buy your argument here.
>>
>> Ok, I need to learn how to do it, so well as to be able to teach
>> somebody else who'd do it.  I am only in the middle.
>
> I don't think that trying to influence IETF standards is the best
> way to avoid an education.

That is right.

>>>> These two directions are actually head and tail of same snake:
>>>> it bites its end, or otherwise put it's a chicken and egg
>>>> problem: if the deployer sees the prototype works then it may
>>>> request IPv6 addressing space from registry, but not before it
>>>> sees it works.
>>>>
>>>> At this point I think this draft is good to say that ULAs are
>>>> useful. Later on maybe less so.  But right now that's
>>>> reflecting real-world situation.
>>>>
>>>
>>> So we disagree. It is not the first time and probably not the
>>> last.
>>>
>>>> That's how I see it, and one's mileage may vary.
>>>>
>>>> But imposing to not do ULA is little reasonable for some test
>>>> deployments.
>>>
>>> I did not say "don't do ULA". I said that the number of
>>> situations where ULA is detrimental vastly outweighs the number
>>> where it is useful.
>>>
>>> Your description above is one of the few cases where it might
>>> not be detrimental. It is not, however, particularly useful vs.
>>> PI or PA.
>>>
>>> As such, I think it is appropriate for the draft to make it
>>> clear that use of ULA should be carefully considered as in most
>>> cases it provides greater detriment.
>>
>> Also make it clear that any other alternative is not easy: it
>> involves delays and money.
>
> I don't buy that argument. Getting it routed is going to cost you
> money regardless of what space you use.

In a sense yes, but one could plan for that, independently of any other
organization.

> If you use ISP provided space, you probably get the space for free.

If this were ISP of 802.11p (WAVE) then yes, but these operators are in 
their very inceptive form these days.  In a few years maybe yes.

> If you use ULA, then you have to get space from the ISP, NAT the ULA,
> and still pay the same money.

Ok, again, this is a cellular operator, (not ADSL, not lab) which does 
give a /64 to an end user.  I think it is very hard to persuade a 
cellular operator to give more than 1 64, not in the immediate future. 
64share is there for this reason, no?

>
> If you want PI space so that you can move amongst different ISPs,
> then, you will need to pay the RIR fees for the PI space, but these
> are relatively minimal.

If I get PI space from an organization, I doubt cellular operator will 
route it for me.  So I end up with again a need to set an anchor 
somewhere else in the infrastructure.  And, if I can do that, I can do 
it for an ULA as well.

>>>> Alex PS: There are also some intermediary alternatives like
>>>> IPv4 transitioning (6to4 and other tunnels), 64share.  Each
>>>> has some inconvenients (6to4 requires both IPv4 and IPv6 on
>>>> cellular, whereas IPv6-only is easier with some operator;
>>>> 64share only allows one subnet in vehicle).  Also one would
>>>> consider asking the cellular operator to implement DHCPv6
>>>> Prefix Delegation, which may also take time.
>>>
>>> I'm not sure how any of that relates to the ULA draft in
>>> question. ULA certainly isn't useful in any of those scenarios.
>>
>> A vehicle holds a 'mobile router' which may act precisely the same
>> as a smartphone and tethering when connecting on cellular.  Except
>> there are more subnets in a vehicle than the single subnet a user
>> may carry.
>
> There are more subnets attached to cellular devices in the future,
> too. I'm still not sure what any of this has to do with ULA.

More subnets attached with a smartphone?  I dont doubt the need exists, 
but 64share won't work there.

>> Similar comparisons apply to 6to4 and DHCP Prefix Delegation -
>> it's just like a smartphone.
>
> But what does that have to do with ULA? ULA is _NOT_ useful in any
> of those cases.

_If_ a smartphone can obtain more than one 64, with DHCP Prefix 
Delegation, then of course ULA is not needed, PI space is not needed, 
64share is not needed.

If a smartphone can not, then one of the above is needed.

Among these: 64share does not work with multiple subnets, PI space 
requires time.

Alex

>
> Owen
>
>
>