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

[Alexandre Petrescu <[e-mail]>]

Le 31/10/2019 à 15:16, Owen DeLong a écrit :
>
>
>> On Oct 31, 2019, at 3:02 AM, Alexandre Petrescu 
>> <[e-mail] <mailto:[e-mail]>> 
>> wrote:
>>
>>
>> Le 31/10/2019 à 04:05, Owen DeLong a écrit :
>>> 8 /64s is a /61.
>>
>> Right, I guess 8 /64s is a /61 because 2^3 is 8, and 3+61 is 64.
>>
>>
> Well, a /60 would include not only ce10..ce17, but also ce18, ce19, 
> ce1a, ce1b, ce1c, ce1d, ce1e, and ce1f.
>
> I’m not familiar with your particular router or its GUI, so I can’t 
> explain why it displays what it does.
>
> 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.


I think that's right.

I think I conclude I get a /61 at home from Free.  I will try to not 
forget this number in future conversations.

(remark, a private email also challenged me on the stability and 
contractuability of this prefix: I must say I dont know; I just know it 
did not change in several years)


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


Noted the IPv4think.

Alex


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