Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

[Alexandre Petrescu <[e-mail]>]

Le 30/10/2019 à 15:27, Radu-Adrian Feurdean a écrit :
> On Thu, Oct 24, 2019, at 11:20, Alexandre Petrescu wrote:
> 
>> In particular, the home networks scenario is very appropriate.
>> 
>> First, I must say that the home network that I use uses a fixed
>> /56 allocated by my ISP.  In this, the prefix never changes, and it
>> is not obtained by DHCPv6-PD - it is guaranteed by contract signed
>> by hand. Such a case could be mentioned, as not being a problem 
>> described in this draft.
> 
> If you are talking about residential service (not 
> business/enterprise-class), I would like to know who your service 
> provider is.

(my correction: I am not at all good at bit fiddling, sorry.  What I get
at home is a /60, I think, not a /56.  Because the CPE GUI proposes me
to split it into 8 /64s).

YEs, it is at home, probably you mean it is residential.  The payment is
a flat 35eur/month.  No special QoS commitments from them, other than a
'noise level' of 55dbm due to the length of the line.

The service provider is Free. ('Free' is its name; it was the first
callable at gratuitous phone numbers when all others requested a payment
in exchange; later they were the first to offer flat rates when the
others were per-connection time; because of that it called itself so).

>> I must say that this kind of software (request a prefix with 
>> DHCPv6-PD, form sub-prefixes, and put them in RAs on the other 
>> interfaces) does not exist as open source or some other available 
>> package.
> 
> Dibbler-client does that by default. Once the delegated prefix 
> (shorter than /64) is obtained, a /64 from that prefix is assigned to
> each interface. With proper radvd.conf configuration (prefix ::/64),
> RAs will be sent for those prefixes.

I did not know.  The difficulty I talked about is to maintain what's in
that radvd.conf in sync with what is dhcpd.conf.  Maybe some software
packages already do it.

Also, because you talk about deriving /64s out of /56: I am not sure
there is a standard way to do it.  Maybe dibbler does it, but I doubt it
is the best way.

> A lot (?? most ??) of CPEs implementing DHCPv6-PD client do this in 
> some form or another. Some do this automatically (take prefixes and 
> assign them to interfaces), other need manual configuration (n-th 
> prefix go to interface ZZZ).

It's good to know.

But again, I doubt these CPEs derive prefixes in the manner that _I_
want it.

For example, I want the /60 to be derived into one /64 and a single
other set of /64s.  I dont want the /60 to be derived into 8 /64s.

I do that to help aggregation and speed up the forwarding process.

Other times I might want to derive that /60 differently.

I dont think there is a standard way to do it.

>> Because of that, I am surprised that you call it 'the most common 
>> deployment scenario'.  Is this a scenario that is _expected_ to be
>>  'common'?
> 
> "Expected enough" to warrant a device to be disqualified as "CPE that
> supports IPv6" if it doesn't work this way. In an ISP environment.

Well.

A CPE that supports IPv6 should run DHCPv6.  A CLient and a Server?
Both?  Just one?

How does CPE propagate the prefixes learned with its CLient to its Server?

>> I would like to request addition of two other scenarios:
>> 
>> - an IoT scenario, in which an IoR Router connects several sensors
>>  to the Internet.  For example, an IoT Router is deployed in a box
>>  at a traffic lights.  The IoT device is the Traffic Lights 
>> Controller connected on Ethernet to the IoT Router.  The IoT Router
>> is connected on 4G.
>> 
>> - a vehicular networks scenario: the On-Board Unit is deployed in a
>> car. This OBU has a 4G interface and an Ethernet interface. There
>> are several computers in the car that need IPv6 addresses.
> 
> Like : you have a mobile phone on a network doing IPv6+NAT64,

My CPE is not doing NAT64, I think.

I dont want NAT64.

> you pout it in tethering/mobile-hotspot mode, and connect several 
> other devices (usually laptops) to that hotspot - they all get IPv6 
> addresses (in the same single /64 that the phone obtained via SLAAC 
> or something else). It is clear that getting a /56 (even a /60 or /62
> would do it) via DHCPv6-PD would be a nicer solution, but when your
> mobile device runs android....

Well.  Android is good in many places and for many goals.

I agree that tethering/mobile-hotspot mode is a good solution in certain
circumstances, like sharing one's smartphone connection to tablets nearby.

However, tethering in IPv6 ('64share' RFC) has some drawbacks: (1) it
does not support more than the WiFi tethered to the cellular (doesnt
support an additional subnet like Ethernet) and (2) the incoming
interface must be cellular (cant be another wifi).

In a car, one has a WiFi hotspot but also lots of Ethernets and CANs.
It's not possible to use 64share to accomodate all that.

Hence, there DHCPv6-PD is not just a nicer solution - it is a requirement.

Other than cars, even at home, one may want a DHCPv6-PD Server on the
CPE for similar reasons.

If one wants to run tethering on a device at home that has no cellular
connection (e.g. a WiFi<->USB, or a USB<->Ethernet device) to extend to
other devices then one cant use tethering ('64share'), must use DHCPv6-PD.

Alex

>