Re: [dhcwg] Adoption call for draft-ren-dhc-problem-statement-of-mredhcpv6-01 - success

["rengang" <[e-mail]>]

Tomek and Bernie:

 

Thank you very much for the interest of the DHC working group in adopting
this draft.

We have revised it in accordance with all the five very valuable comments
put forward by Tomek. 

I have uploaded the revised draft as
draft-ietf-dhc-mredhcpv6-problem-statement-00.

We are looking forward to expand and improve it with the help and guidance
of DHC Working Group.

 

Thanks a lot.

 

               Ren Gang

 

 

>> From: *Tomek Mrugalski* <[e-mail]
<mailto:[e-mail]&gt> >;

>> Subject: [dhcwg] Adoption call for

>> draft-ren-dhc-problem-statement-of-mredhcpv6-01 - respond by May 9th

>> To: <[e-mail] <mailto:[e-mail]>  <mailto:[e-mail]>>

>> 

>> This message initiates a three weeks long DHC WG adoption call on:

>> 

>> Title: Problem Statement of Multi-requirement Extensions for DHCPv6

>>
https://tools.ietf.org/html/draft-ren-dhc-problem-statement-of-mredhcpv6-01

>> 

>> Please respond by May 9th.

With my co-chair hat off, I support adoption of this document.

 

Here's a couple comments.

 

1. Section 1: update references to from 3315bis to RFC8415.

 

2. Section 1: IPv6 hosts => IPv6 nodes. DHCPv6 often provisions PD to

routers.

 

3. Fig.1 says a relay does message processing functions. Yes, it does

encapsulation and forwards the packets further (sometimes adding extra

options to the encapsulation layer), but it doesn't process the packet.

I would rephase this as "message relaying functions".

 

4. Section 4.2.4: "DHCPv6 servers try to generate random addresses".

That's not true. Each implementation uses its own allocation strategy.

It may be something simple or very complex and almost always it's

influenced with various policies configured by the sysadmin. It would be

better to say "Currently, the DHCPv6 servers assign addresses, prefixes

and other configuration options according to their configured policies."

 

5. Section 5 The motivation talking about countries wanting to control

resources outside of its domain is a bit risky and may raise some

eyebrows if this I-D goes to IESG. I would recommend using more generic

language here that would talk about enforcing local policies. As an

example you may give allowing access for students of the university and

preventing access for guests unless they sign up for some guest

registration system.

 

Besides the extensions mentioned in the text, there are many other

administrative mechanisms available in most DHCP implementations. One

popular feature is a host reservation, where you can reserve certain

parameters (IP addresses, prefixes, options) to specific devices. Some

deployments choose to not serve any addresses unless your device is on

their customer/student/employer list. Another  popular and powerful

feature is client classification. Many servers, including Kea, allow

defining classes, associating certain parameters or grant addresses from

restricted pools and then assigning incoming packets to those classes.

Host reservations and classes are often used together.

 

For example, you can define 3 pools: guests, students and professors.

And there would be a list of known devices with each assigned to certain

class. Once a device does DHCP, it is being looked up in host

reservations database and then assigned to specific class (with students

getting access to lab and e-learning platform, and professors getting

extra access to additional faculty services). All of those can be done

without writing any line of API extensions or hooks. It's just a

configuration of existing policy mechanisms.

 

Anyway, the I-D looks good. I look forward for the WG to expand and

improve this document in the future.

 

Tomek