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

From: Tomasz Mrugalski <[email-masked]>
Date: Thu, 27 Oct 2011 14:17:58 +0200

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Oct 2011 14:23:49 +0200

Can you provide software for this?  Please contact me off-list if yes.

Alex

Le 27/10/2011 14:17, Tomasz Mrugalski a écrit :
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: maximilien mouton <[email-masked]>
Date: Fri, 28 Oct 2011 12:29:50 +0200

Tomek,

You use a wrong argument for criticize our proposition of defining 
separate options.
You quote Ted saying it is not a good idea having two different ways 
providing the same information but it is actually not what we proposed.
We proposed the same organization than DHCPv4 option router and classful 
static route option defined in RFC 2132 ie not allow route option to 
provide default route and use a specific option for default route.
Thus there is no interoperability problem in our proposition.

But this mail doesn't aim to continue this discussion.

Anyway my only comment is that I think lifetime field of the default 
route should be up to 65535 (no more for compatibility reasons) with a 
recommendation to limit it at 9000 to be consistent with ND.

Maximilien