search

dhcwg / yang

A workplace for IETF drafts related to DHC WG and YANG
1 stars 1 forks source link

Definition of server rules for serving client request from correct address/prefix pools #8

Open dhcwg opened 6 years ago

dhcwg commented 6 years ago

Currently, there is no way of defining server rules for parsing input values in the client's request/relay message to the correct address pool. As there are a number of ways that this can be done, there should be a way of defining this logic.

dhcwg commented 6 years ago

Note comments https://github.com/iffy50/draft-ietf-dhcpv6-yang/issues/8#issuecomment-352323950 and https://github.com/iffy50/draft-ietf-dhcpv6-yang/issues/8#issuecomment-353236483 in the old repo.

zihaohe123 commented 6 years ago

Now I think this can be achieved by referring to Section 13.6 in Kea guide - configuring subnets with class classification. I'll try to figure out a method to define this in YANG syntax.

zihaohe123 commented 6 years ago

I added 'client-class' under address-pool and pd-pool and it is is non-mandatory. If this is instantiated, the address/prefix will only be assigned to the corresponding clients with the same class. And the server gets to know the client's class from values in VENDOR_CLASS_OPTION. May this is a way to define this logic.

bevolz commented 6 years ago

Client classing is generally much more complex. I would think Enterprise-id would be one way (whether from class or identifying options (16 & 17)), we support expressions that can use almost any data in packet. And for DOCSIS, that is critical because one of vendor options tells what type of device. Not sure how we can handle that as support for this greatly varies in implementations.

On Feb 25, 2018, at 1:30 AM, Zihao He notifications@github.com<mailto:notifications@github.com> wrote:

I added 'client-class' under address-pool and pd-pool and it is is non-mandatory. If this is instantiated, the address/prefix will only be assigned to the corresponding clients with the same class. And the server gets to know the client's class from values in VENDOR_CLASS_OPTION. May this is a way to define this logic.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/dhcwg/yang/issues/8#issuecomment-368287218, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABm3YQ-XaGdHKPDXo7jy_pWvorU55GgMks5tYP4CgaJpZM4Rh9zC.

iffy50 commented 5 years ago

The kea DHCP modules (https://gitlab.isc.org/isc-projects/kea/tree/master/src/share/yang/modules) define a client-class yang type with a string for the data, which is refinable based on where it is used (e.g. pool-client-class uses client-class and offers a refine leaf). It is not clear to me how the defined string in either the current module, or the kea module should be formatted to match particular options or fields in a client's messages. Can we include example text on how this should be used?

iffy50 commented 5 years ago

I've put together a new client-class-id group in ietf-dhcpv6-types which allows for the definition of different types of class identifiers (choice statement with: text-literal, received-interface, packet-source-address, packet-dst-address, relay-link-address, relay-peer-address, vendor-class-present, vendor-class-option-ent-num, vendor-class-option-data - these can be extended as needed). The client-class node in server address-pools and pd-pools is now a list referencing the client-class-id group - this allows the group to be referenced as many times as needed.