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

From: Li HUANG <[email-masked]>
Date: Fri, 1 Nov 2019 16:31:34 +0800

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 <
[email-masked]> 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
> > [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
> >
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Li HUANG <[email-masked]>
Date: Sun, 3 Nov 2019 19:49:51 +0800

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
[email-masked]
Li HUANG

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

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 4 Nov 2019 15:17:20 +0000

See below (BV>).

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Thursday, October 31, 2019 4:14 PM
To: [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

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 :
> publication or not. If you have minor editorial comments, you may send 
> them to the authors directly.
> 

Is it the link-layer address that was assigned previously by DHCP, or is it a temporary, or is it?

BV> This is whatever link-layer address that the device may have - such as a temporary address it may have generated. The server does not have to honor that request as the discussion points out.

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?

BV> No. I don't see how the draft could do that. Per above, if the device has an address in the non-global space, it can request to continue using it.

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?

BV> That really is a policy issue for the DHCP server. There are many possibilities as to how this could be implemented such as:
1) Use an algorithm that given some input (such as client-id option), will always generate a stable mac address, OR
2) Once an address has been assigned, retain the binding between it and the client for a duration (either this is the valid lifetime or may be some additional lifetime beyond that that may not be communicated to the client)

> (typically 6, for a link-layer-type of 1 (Ethernet)). A two octets 

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?

BV> 128 is never mentioned explicitly in this document. The figure using the vertical pipes in this manner is to say that this is a variable length field - there is no implication that of the size -- yes, it looks to be a multiple of 4 octets but that was just to make it easier to show the remaining fields (wrapping them between two rows makes them difficult to read). 

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

BV> Correct. This is variable length field (link-layer-address is variable and depends on link-layer-type/link-layer-len).

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

BV> I'm not sure what the problem is here? 

BV> Huh? A block is defined as the starting address plus the number of addresses. So, the 4 address ...0a, 0b, 0c, and 0d are represented by a starting address of ...0a and length of 3 (because it is "extra-addresses" - having 0 addresses assigned is useless).

Or only the starting address is included in full and the number of addresses in the field 'extra-addresses?

BV> See previous comment.

Shouldnt one rather encode the set of MAC addresses like the IPv6 address/plen notation? (rather than including fully each address).

BV> plen only allows allocating in powers of 2. 

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?

BV> Prefix delegation and mac address assignment are different and are used for different purposes. The mac-address is what the client will use to communicate at layer 2; prefix delegation is layer 3 issue. 

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

BV> This is completely outside the scope of this document. Other documents cover how (or if) a link layer address is used for form an IPv6 address.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 4 Nov 2019 17:52:49 +0100

Le 04/11/2019 à 16:17, Bernie Volz (volz) a écrit :
[...]

>> 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?
> 
> BV> 128 is never mentioned explicitly in this document. The figure
> using the vertical pipes in this manner is to say that this is a
> variable length field 

Maybe vertical ellipsis?

OLD:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OPTION_LLADDR        |          option-len           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       link-layer-type         |        link-layer-len         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                     link-layer-address                        |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      extra-addresses                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      valid-lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                      LLaddr-options                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NEW:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          OPTION_LLADDR        |          option-len           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       link-layer-type         |        link-layer-len         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     link-layer-address                        |
    .                                                               .
    .                                                               .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      extra-addresses                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      valid-lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                      LLaddr-options                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 4 Nov 2019 18:03:51 +0100

> BV> Huh? A block is defined as the starting address plus the number 
> of addresses. So, the 4 address ...0a, 0b, 0c, and 0d are
> represented by a starting address of ...0a and length of 3 (because
> it is "extra-addresses" - having 0 addresses assigned is useless).

I agree with you.  02:04:06:08:0a-length-3 (or another agreed textual
representation of blocks) is a brief way to express these 4 addresses.

For the textual representation of MAC address blocks I was thinking like
of the IPv6 style 02:04:06:08:0a/plen, but that would be longer to
express just these 4 addresses.

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 4 Nov 2019 18:50:05 +0000

Oh, I see ... you wanted a special notation.

I'm not sure that is worth it to define this, but something to perhaps discuss further.

- Bernie

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Monday, November 4, 2019 12:04 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01

> of addresses. So, the 4 address ...0a, 0b, 0c, and 0d are represented 
> by a starting address of ...0a and length of 3 (because it is 
> "extra-addresses" - having 0 addresses assigned is useless).

I agree with you.  02:04:06:08:0a-length-3 (or another agreed textual representation of blocks) is a brief way to express these 4 addresses.

For the textual representation of MAC address blocks I was thinking like of the IPv6 style 02:04:06:08:0a/plen, but that would be longer to express just these 4 addresses.

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 4 Nov 2019 18:51:38 +0000

Hi:

Ok, yes. Based on RFC8415, we really should put dots here for things that are variable in size.

- Bernie

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Monday, November 4, 2019 11:53 AM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01

Maybe vertical ellipsis?

OLD:
     0                   1                   2                   3

NEW:
     0                   1                   2                   3

Alex

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 13 Nov 2019 21:43:23 +0000

Hi:

As a co-author of the draft-ietf-dhc-mac-assign (and with WG co-chair hat off), I support both of these documents moving forward.

- Bernie

-----Original Message-----
From: dhcwg <[email-masked]> On Behalf Of Tomek Mrugalski
Sent: Tuesday, October 29, 2019 9:51 PM
To: [email-masked]
Subject: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17

Hi,
This mail initiates a Working Group Last Call on two related IDs:

and

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.

Cheers,
Tomek

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sun, 17 Nov 2019 18:08:40 +0800

Hi,

Also as c-o-author, I support both documents moving forward.

Thanks,

Carlos

On Thu, Nov 14, 2019 at 5:43 AM Bernie Volz (volz) <[email-masked]> wrote:

> Hi:
>
> As a co-author of the draft-ietf-dhc-mac-assign (and with WG co-chair hat
> off), I support both of these documents moving forward.
>
> - Bernie
>
> Subject: [dhcwg] WGLC on draft-ietf-dhc-mac-assign-01 and
> draft-ietf-dhc-slap-quadrant-01 - respond by Nov. 17
>
> Hi,
> publication or not. If you have minor editorial comments, you may send them
> to the authors directly.
>

-- 
Special Issue "Beyond 5G Evolution":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g

---

From: [email-masked]
Date: Sun, 17 Nov 2019 18:36:26 +0100

Hi,

As a non author, I would like to support both documents as well.

thanks
udo

On 11/17/19 11:08 AM, CARLOS JESUS BERNARDOS CANO wrote:
> On Thu, Nov 14, 2019 at 5:43 AM Bernie Volz (volz) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi:
>
>     As a co-author of the draft-ietf-dhc-mac-assign (and with WG
>     co-chair hat off), I support both of these documents moving forward.
>
>     - Bernie
>
>     From: dhcwg <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Tomek Mrugalski
>     To: [email-masked] <mailto:[email-masked]>
>     publication or not.. If you have minor editorial comments, you may
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 18 Nov 2019 03:48:17 +0800

Disclaimer: I used to be involved in the draft-ietf-dhc-mac-assign a
year ago. I asked the other authors to remove my name from it, but they
feel my contributions were significant enough to keep it on.

So it's with my co-chair and co-author hats off, I support this work
moving forward. However, I have some comments that should be addressed.

Nitpicks:
Section 6, bullet numbering is wrong (no item 2)
Section 6, bullet 3: block of address => block of addresses

Section 6 properly explains that the client is supposed to set the valid
lifetime field to 0. I'd like to see a text for the other side: the
server MUST ignore the valid lifetime value.

Nitpick: "a IA_LL" => "an IA_LL". RFC8415 uses an for all IA options.

"The server MAY alter the allocation at this time." This is technically
incorrect. Server doesn't have any allocation yet, it's about to make
one. Better text would be: "The server allocates block of addresses
according to its configured policy. The server MAY assign a different
block than requested in the Request message."

Text in section 10.2: "This value can be only sent by a client that
requests a new block.". There are two issues with this text. First, I
would rephrase this text. The sentence as written now suggests that the
only entity allowed to set this field is a client and only under certain
circumstances. Maybe something like this: "A client is only allowed to
set this value when requesting a new block?". The second problem with
this text is that it's not really true, is it? What about renewals?
Client is expected to send the block it already has for renewal.

"extra-addresses - A four octets long field". Would be useful to clarify
that it's an unsigned field encoded in network byte order.

End of section 10.2: "More than one LLADDR option can appear in an IA_LL
option." This seems to be in contradiction with earlier text that says
"Therefore, if a client wants more addresses at a later stage, it SHOULD
send an IA_LL option with a different IAID to create another "container"
for more addresses.". So what are the circumstances when more than one
LLADDR is present in IA_LL? If there are none, perhaps best would be to
remove this sentence?

Section 13 should probably mentioned that there is no duplicate
detection mechanism such as DAD for IPv6. It's not really a problem,
though. A malicious node can start using any MAC address and doesn't
have to go through the hassles of implementing this protocol.

I hope to review the second draft in the coming days. Will send a
separate mail.

Thanks,
Tomek

---

From: Lin He <[email-masked]>
Date: Mon, 18 Nov 2019 15:20:02 +0800

Hi, all!

I support both of these documents moving forward.

<[email-masked]> 于2019年11月18日周一 上午1:36写道：

>> publication or not.. If you have minor editorial comments, you may send
> dhcwg mailing [email-masked]://www.ietf.org/mailman/listinfo/dhcwg
>

-- 

    Yours Sincerely,

*   Lin He*