[mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option

[Tomasz Mrugalski <[e-mail]>]

Dear Chairs, Dear MIF,

DHCPv6 Route Option draft has been presented in MIF several times. It
was also presented in DHC WG and most* (see below) comments were addressed.

I would also like to point out that this draft incorporates changes
after Routing Directorate review, especially insightful comments from
Joel Halpern about potential problems in networks that use dynamic
routing. The lastest (-03) drafts contains clear warning that
configuring routing over DHCPv6 in networks that use dynamic routing is
a very bad idea (unless you exactly now what you are doing).

* Authors chose to not incorporate some of the comments, raised by
authors of dlro draft. There was a discussion in MIF list. Route option
authors believe that:

1. defining separate option for just default route would be wrong. Let
me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways
of specifying the same information—it creates a very clear potential for
interoperability problems.". On a related note, I was involved in work
on DS-Lite configuration over DHCPv6 and we initially had the same idea
- define two options (address and FQDN) for the same thing. This
approach was firmly rejected during IESG review. The message was clear:
"choose one option".

2. conveying MAC (or link-layer in general) address is not necessary.
There are other mechanisms like ND to obtain that information. Forcing
this information on every client is just a waste of space as all clients
that I know of can obtain this information on their own. They can do
that in a timely manner, so raised argument about speed-up is not valid
in my opinion. Another aspect is operational consideration. It would be
very cumbersome to deploy and use. If operator changes interface in its
router, DHCP configuration had to be updated and reconfigure procedure
initiated. It could work in theory, but reconfigure is not commonly
supported. DHCP server configuration would require knowledge of
link-layer addresses of announced router(s). We could gain nothing by
including MAC address, but get a lot of problems in the process.
Therefore dhcpv6-route-option authors chose to not include link-layer
information field.

I would like to point out again that route-option proposal is
extensible. It is designed as a minimal useful set of informations
necessary for routing configuration. There are many more aspects of
routing that may be useful in *some* cases. Therefore we made it clear
that proposed options are extensible. If there are valid cases when
extra information is useful, it should be defined as extension option.
That's they recommendation I offer to anyone who says "can you add
parameter X to route options? I really need it".

To summarize this summary, we believe that mif-dhcpv6-route-option draft
received enough reviews by experts in MIF, DHC and routing fields and is
ready for WGLC. Therefore I'd like to ask MIF chairs to announce one.

If we choose to have LC done in a timely fashion, we could discuss the
results in Taipei. If that is the case, I would like to request time
slot in Taipei meeting. I can't guess how many comments we will receive
during WGLC, but I hope 10 or 15 minutes will be enough.

Cheers,
Tomek