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

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
>