Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

[Li HUANG <[e-mail]>]

If on the case of Switch defaulted sntp time server unable kept continued ,
sometimes turn on device , the clock would go back default time Nov. 2018
when it is 2019 configured times afterward, having to add the clock servers
four more , would this be possible cause the different sntp running one OS
by different time on the real device or/and at the virtual mirror devices
mimic ?

PD-Prefix not for Rv having mode , it can only give the a number but Prefix
IPv6 to be configurable ?   Needless to say the 2 prefix-PD case, the
device is depending on the region to have different features ?



Sincerely
[e-mail]
Li HUANG

On Fri, Nov 1, 2019 at 4:31 PM Li HUANG <[e-mail]> wrote:

> Am afraid the ISP mine just playing the LLADDR as,  its dhcpv6 server IP
> default never has been offered to not listing (but ever) route, switch my
> Cisco device for configuration aim.
>
>
> For instance SG3xx of Cisco , it can set the mac filter and control first
> and arp , then IP . Did meet the one MAC with plenty of over 50 IPv4 groups
> and filtered them ,,then they appeared again ?
> To the IPv6 prefix would be depended on ISP mainly for the 64bit ahead of
> , so ISP primary function on its accuracy .  And one mac can also create
> many IPv6 for the WAN prefix according to the subnet address length given
> to the next stream its .
>
> HOST , ISP , and Route are big 3 players inside the WAN.
>
>
> Sincerely
> Li HUANG
>
> On Fri, Nov 1, 2019 at 4:13 AM Alexandre Petrescu <
> [e-mail]> wrote:
>
>> I discuss because comments are requested, but I do not oppose advancemet
>> of this draft.
>>
>> The questions I make below are more like brainstorming, because I do not
>> use the mac-assign mechanism myself.
>>
>> Le 30/10/2019 à 02:51, Tomek Mrugalski a écrit :
>> > Hi, This mail initiates a Working Group Last Call on two related
>> > IDs:
>> >
>> > Link-Layer Addresses Assignment Mechanism for DHCPv6
>> > draft-ietf-dhc-mac-assign-01
>> > https://tools.ietf.org/html/draft-ietf-dhc-mac-assign-01
>> >
>> > and
>> >
>> > SLAP quadrant selection options for DHCPv6
>> > draft-ietf-dhc-slap-quadrant-01
>> > https://tools.ietf.org/html/draft-ietf-dhc-slap-quadrant-01
>> >
>> > Authors believe those drafts are ready for WGLC. Please post your
>> > substantial comments and your opinion whether those are ready for
>> > publication or not. If you have minor editorial comments, you may
>> > send them to the authors directly.
>> >
>> > Please post your comments by Nov. 17th.
>>
>> draft says:
>> > DISCUSSION: A device may send its link-layer address in a LLADDR
>> > option to ask the server to register that address to the client (if
>> > available), making the assignment permanent for the lease duration.
>> > The client MUST be prepared to use a different address if the server
>> >  choses not to honor its hint.
>>
>> I agree with the idea to request to register.
>>
>> Which link-layer address may the device send in a LLADDR option?
>>
>> Is it the link-layer address that was assigned previously by DHCP, or is
>> it a temporary, or is it?
>>
>> The IoT devices and VMs  I have seen, if they have the capability to
>> have a MAC address, then they already have something in there, like 0s,
>> or like random bits, if not an IEEE-assigned address with OUI and so on.
>>
>> Will this draft forbid these IoT devices and VMs to use their existing
>> MAC addresses?
>>
>> On another hand, can the MAC address that the device imposes (registers)
>> to the DHCP server be used as a key to make the server always allocate
>> the same IP address to the Client?
>>
>> > link-layer-len  Specifies the length of the link-layer-address field
>> >  (typically 6, for a link-layer-type of 1 (Ethernet)). A two octets
>> > long field.
>>
>> But the preceding figure says that the length is 128bits(?) precisely -
>> there are no vertical dots, but vertical pipes '|'.  The rest of bits is
>> padding 0s (leading? trailing?)?  MAC addresses longer than 128 bits
>> arent accepted?
>>
>> There are link-layers from IEEE that have lengths 16bit (short addresses
>> in 802.15.4) and also 64bit (802.15.7 VLC Visible Light Comms).
>>
>> > and may specify a specific address or address block as a hint for
>> > the server.
>>
>> I fully agree with the idea of requesting more than just one MAC
>> address.  You call that a 'block'.  The question is how to represent
>> (and implement) such a block.
>>
>> > For example: link-layer-address: 02:04:06:08:0a and extra- addresses
>> > 3 designates a block of 4 addresses, starting from 02:04:06:08:0a
>> > (inclusive) and ending with 02:04:06:08:0d (inclusive).
>>
>> Are the addresses ending in 0a, 0b, 0c and 0d each included in Figure3?
>>   In which field?
>>
>> Or only the starting address is included in full and the number of
>> addresses in the field 'extra-addresses?
>>
>> Shouldnt one rather encode the set of MAC addresses like the IPv6
>> address/plen notation? (rather than including fully each address).
>>
>> What would be the relationship between a MAC block and an IP prefix?  In
>> Prefix Delegation one would like to delegate always the same prefix to
>> the same MAC address, to facilitate application continuity; with this
>> address block concept here, would we talk about delegating an IP Prefix
>> to a MAC block?
>>
>> Finally, would one use a delegated MAC address to form an Interface ID
>> and further prepend a prefix from RA to get a more privacy IP address?
>> (rather than using the built in MAC address that is centrally
>> administered and has privacy risks).
>>
>> Alex
>>
>>
>> >
>> > Cheers, Tomek
>> >
>> > _______________________________________________ dhcwg mailing list
>> > [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>> >
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
>