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

[Owen DeLong <[e-mail]>]

> On Nov 4, 2019, at 00:29 , Alexandre Petrescu <[e-mail]> wrote:
> 
> 
> 
> 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.

Or get a router with a good CLI such as a Juniper SRX series.

Owen

> 
> 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