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

[Alexandre Petrescu <[e-mail]>]

Le 31/10/2019 à 15:16, Owen DeLong a écrit :
[...]
> 
> I’m not familiar with your particular router or its GUI, so I can’t 
> explain why it displays what it does.

I think I understand you.  These GUIs are not only difficult to explain
to others but also difficult to manipulate.

The best is to replace manual filling of prefixes in GUI fields with
automated prefix delegation.

Alex

> 
> It may simply be limited to 8 subnets that it can handle. It may be 
> something else.
> 
> I doubt that it has anything to do with your neighbor as your
> neighbor would get their own separate PD. They might have the
> opposing /61 (ce18..ce1f), but in that case they would still also
> have 8 subnets in that case.
>> 
>> Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an 
>> annotated figure of GUI below).  They are 8 /64s.  I dont see ce18,
>>  neither ce19 in the GUI.  Might it be that my neighbor gets ce18
>> and ce19, but it would mean s/he cant get more than 2 /64s.  Might
>> it be that free hides ce18 and ce19 for something else inside my
>> home that they dont tell me what.  Might it be they expect me to
>> ask them for more addresses later.
>> 
>> Whether I get a /61 or a /60 at home is still a valid question for
>> me.
>> 
>>> 16 /64s is a /60. 256 /64s is a /56. You should be getting 65,536
>>> /64s (a /48) and if I were you, I would complain to any ISP that
>>> gave me less.I
>> 
>> I keep the /48 request in mind for my next interaction with their 
>> service, because I have many things to ask.
>> 
>> I suppose they will ask me, in return, if I already spent the 2^61
>>  addresses they already gave me.
>> 
> This is IPv4think. In the IPv6 world, the intent is to provide large
>  blocks to avoid future need to renumber and routing table
> pollution.
> 
> Owen
> 
>> Alex
>> 
>> 
>> 
>> PS:
>> 
>> For information, see below an annotated copy of the GUI listing the
>>  form of the 8 prefixes I see in GUI on CPE.
>> 
>> One may notice things to complain about: the use of ff:fe in the
>> LL, the way they call it 'Prefix Delegation' without using
>> DHCPv6-PD and the optional firewall IPv6 activation (off by default
>> - they dream :-)
>> 
>> You may understand why I say I have many things to ask them.
>> 
>> 
>> <mohkmddlfcdkakja.png>
>> 
>> 
>> 
>>> Owen
>>> 
>>>> On Oct 30, 2019, at 9:29 AM, Alexandre
>>>> Petrescu<[e-mail]>  wrote:
>>>> 
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> _______________________________________________ v6ops mailing
>>>> list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>