[dhcwg] Comments on draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

[Tomek Mrugalski <[e-mail]>]

On 30.07.2012 03:35, Leaf yeh wrote:
> Dear DHC folks,
> 
> The draft (ver.-08) & the proposed (OPTION_PREFIX_POOL) on the
> agenda of IETF84 DHC session 
> (https://datatracker.ietf.org/meeting/84/agenda/dhc/ ), is waiting 
> for your review and comments.
Hi,

You've asked for it, so here are my comments. Although there are many
things mentioned below, I think the draft is a good idea. It is in a
good shape and I support it. None of the things mentioned below are
show-stoppers, and most can be easily fixed.

I will send out separate mail to respond to adoption call.

Generic comments:

- Multiple prefix pools seem to be allowed (section 6, paragraph 7
  suggests that). It may be useful to note that multiple prefix pools
  must not overlap.

- There are many normative looking words (must, shall etc.) that are
  not capitalized.

- Have you considered defining new leasequery query type:
  QUERY_BY_PREFIX_POOL? Server could return all leases that
  belong to specified prefix pool. I think it would be easier to
  implement one new query type than modifying the code for existing 3
  query types.

- Since your option affects how existing query types in leasequery
  work, the front page of the draft should have "updates RFC5007,
  5460 (if approved)" clause.

- I think I have commented on this before, but I can't find it anywhere,
  so I'll restate my concerns again. This is basically a signalling
  protocol on top of normal exchange. In its current form it allows
  server to make strange things like make the pool active when
  responding to RELEASE or saying that the pool is released when
  assigning a prefix in response to REQUEST.

- That draft was written in BBF networks in mind, but it can be used
  in a general case as well. A statement to point that out should be
  added.

Comments specific to the text:

- Section 1: This is really a nit-pick style comment  "The DHCPv6
  protocol". I always have problem how to write it. Adding protocol
  after DHCP is redundant, as P in DHCP stands for protocol. On the
  other hand, removing "protocol" would make it less readable by people
  who don't know what DHCP acronym stands for. I think it probably
  should stay as it is.

- Section 1, second paragraph. You mentiond RRs without defining that
  acronym. Although it is later explained in section 2, it would be good
  to replace its first use with "Requesting Router (RR)".

- Section 1. First paragraph on page 4. "Bulk Leasequery [RFC5460]
  specifies a mechanism for bulk transfer of the binding data of each
  delegated prefix from the server to the requestor (i.e., a DHCPv6
  relay agent)". While requestor is typically the relay agent, it
  doesn't have to be. It may be a separate entity as well. I would
  replace "i.e." with "typically".

- Section 1, the last paragraph. "The automatic mechanisms described in
  this document depends". It should be "mechanism depends" or
  "mechanisms depend".

- Section 2, Requestor definition. RFC5007 defines requestor as a note
  that sends leasequery messages. While it is typically a router, it
  doesn't have to be one. Requestor may be a separate tool that can be
  run on hosts or routers alike.

- Section 4. ipv6-prefix should be of variable length. In most cases the
  prefix used here will be /56 or even shorter. That will result in at
  least 9 bytes being zeros. BTW This approach will be recommended in
  the next version of draft-ietf-dhc-option-guidelines.

- Section 4. It is customary to include list of messages that MAY/MUST
  NOT include that option. Something like "Server MAY include this
  option in RELAY-REPL if relay included OPTION_PREFIX_POOL in ORO
  option in RELAY-FORW. It MUST NOT appear in any messages sent by
  clients. It MAY/MUST NOT appear in LEASEQUERY message.".

- Section 4. "If the administrative policy on the server does not permit
  to support route aggregation on the DHCPv6 relay agent, the status of
  the prefix pool will always be 'Released'." Wouldn't it be better to
  just not include OPTION_PREFIX_POOL?

- Section 5, second paragraph. "The relay agent should include the
  Interface ID option". Is this normative language? I think it is, so it
  should be "SHOULD".

- Section 5. Consider the following scenario: There are X requesting
  routers behind a relay. Server is configured to allow route
  aggregation, so pool option is sent. Then administrator decides to
  stop using aggregation, so he turns it off. When X+1 client comes in,
  the server does not send PREFIX_POOL anymore, so according to
  paragraph 4 in section 5, relay must withdraw the associated
  route. How are the first X clients reachable? I suppose the relay
  must keep routes to them anyway and the one received in PREFIX_POOL is
  an additional one, not a replacement, right?

- Section 5. The last paragraph about leasequery should probably be
  moved to a separate section "Leasequery requestor behavior".

- Section 6, paragraph 2. "After receiving the Option Request option
  (OPTION_ORO, 6) requesting the Prefix Pool option
  (OPTION_PREFIX_POOL, [TBD]) in the relay- forward messages of the
  PD". What does PD mean in this context? I think you meant
  "relay-forward messages that encapsulate messages with IA_PD
  options". It's awfully lot of words, but I'm not sure how to say it
  simpler.

- Section 6, paragraph 6. "When the administrator of the server changes
  the setting not to support route aggregation on the relay agent for
  the particular prefix pool, the status of the prefix pool may change
  from 'Active' to be 'Released' if at least one delegated prefix
  within the prefix pool has the valid lease.". I think once
  administrator disables it, the server should always set status to
  released. The "if at least one..." part in not necessary.

- Section 6, paragraph 6. Why does the server have to send RECONFIGURE?
  So the relay can re-learn RR prefixes once aggregation has been
  disabled? It is related to my question about RR remembering (or not)
  the specific routes. Anyway, it would be less intrusive to say that
  relay must use leasequery to learn existing delegations than forcing
  all clients to do reconfigure, especially that for clients nothing
  will change. Also, keep in mind that RRs may not support reconfigure
  as it is an optional feature.

- Section 6, last 2 paragraphs. I would move discussion about leasequery
  to a separate sub-section.

- Section 6, last paragraph. Why repeating prefix pool in every
  client-data option? It will all contain the same value. It would be
  more reasonable to send it back only one or even not send it at all
  if requestor sent prefix pool option. If requestor did that, are there
  any cases where server could send back the prefix pool option with
  different values than the requestor asked for? I don't think so.

- Section 7. Security consideration should also reference section 15 of
  RFC3633.

Questions:
1. Let's assume the PE router announces 2001:db8:1::/48 prefix that is
split into /56 prefixes. Someone tries to reach a customer that is
currently offline. What is PE supposed to do with those packets?
Respond with ICMP type=1 code=0 (no route to destination)?

2. PE has a 2001:db8:1::/48 prefix and there are 2 prefixes delegated
to clients: 2001:db8:1:8000::/64 and 2001:db8:1:8001::/64. The
admnistrative policy does not allow route aggregation, so
OPTION_PREFIX_POOL has status set to release. Is PE allowed to
aggregate both routes anyway and announce 2001:db8:1:8000::/63?

Perhaps allowing such behaviour could be defined as status code = 2. I
don't know if controlling this is a good idea, so feel free to ignore
this suggestion.

Ok, that's it. Sorry for sending such long and boring mail. I hope you
find at least some of those comments useful. Again, despite numerous
comments, I really support it.

Tomek