Subject: Re: [mif] Review of draft-mouton-mif-dhcpv6-drlo-01

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 11 Jul 2012 16:58:12 +0200

Ref: draft-mouton-mif-dhcpv6-drlo-01

Kostas,

Thank you for the private email.  Allow me to comment publicly on the
mailing list, by extracting the comments from the pdf, as below:

Le 07/06/2012 17:03, Konstantinos Pentikousis a écrit :
> Dear Alexandru, all,
>
> I read your I-D and I found it quite interesting. Please find
> attached some comments and minor editorial suggestions. Just my
> $0.02. Feel free to integrate or ignore :)

draft says:
> Neighbor Discovery protocol [RFC4861] is currently considered as the
> best way for providing a default router to a client in IPv6 networks.
> Hence it was not considered necessary for DHCPv6 [RFC3315] to have
> this feature. But recently, some deployment scenarios express a need
                               ^^^^^^^^^^^^^^^^^^^^^^^^^
> not to use neighbor discovery autoconfiguration mechanism.

Commenter says:
> Could add a few sentences or a ref?

I may add reference to the future deployments considered in the projects
I work now.  Is this that may be useful?

OTherwise, do you know of some particular deployment context which
considers the use of IPv6 but without ND?  If yes, I am ready to take
text if you wish to formulate something?

draft says:
> The distinction among the default routes (once installed on a
> Client) can be realized according to various criteria: (1) use a form
> of Preferences, new extensions similar to RFC 4191, (2) use the
> Lifetime communicated by the mechanism of this draft to distinguish
> among default routes according to new rules, (3) use a random
> function to pick a default route, (4) use a new interface name in the
> ORO and in the Ack to specify which default route uses which
> interface, (5) use a new field containing a source address which the
> Client must use for a particular default route, and more.

Commenter says:
> I don't get why this para belongs to Sec. 3.

Let me explain.  In the MIF Working Group the use of multiple interfaces
on the same terminal is considered.  Some problems may arise when two
default routes are communicated to a Terminal - this latter wonders
which of the two default routes to use?  In this paragraph we propose
some way to solve the conflicts between the presence of two routes.  I
could imagine this would be in the scope of MIF WG.

draft says:
> router_lifetime - 16-bit unsigned integer. Router lifetime in units
> of seconds. Limit value is 9000 and 0 SHOULD NOT appear according to
>  section 6 of [RFC 4861].

Commenter says:
> MUST NOT, instead?
>
> [RFC4861] sec. 4.2, as you may know, also uses SHOULD NOT ("A
> Lifetime of 0 indicates that the router is not a default router and
> SHOULD NOT appear on the default router list. ")
>
> A "0" would indicate this is not a default router in a default router
> list (kind of an oxymoron) [RFC4861, as you cite it, "A value of zero
> indicates that the router is not to be used as a default router."] .
>
>
> If it remains "SHOULD", and the received list includes only routers
> with router_lifetime=0 (one or more router_address'es), what should
> the receiving client do?

I agree with you.  Intuitively, I would say that indeed, the
router_lifetime MUST NOT be set to 0.  This would maybe be immediately
clear, no further clarification needed.

As per your question what would happen if we left "SHOULD NOT 0" instead
of "MUST NOT 0" then it means that sometimes a default router could have
the value of this lifetime 0.  Maybe, when the lifetime is 0, then a
particular behaviour of a default router could be specified.

Draft says:
> Moreover this optimization has been implemented and does not require
>  a huge amount of intellectual effort (around 10 extra lines of
> code).

Commenter says:
> Add ref?

Well, informally speaking, this is the result of an implementation work.
  The software is internal here at work, not released to the public.  But
of course, we could add a reference to it.

Draft says:
> When a default router lifetime is equal to 0 it MUST be deleted from
>  the Default Router list, Neighbor cahce and other related Fowarding
>  Information Bases.

Commenter says:
> What does the implementation mentioned above do when all lifetimes
> are 0?

When that lifetime, in a particular linux kernel version, expires
(becomes 0) then the entry is deleted - existing vanilla implementation
does so.

If one new implementation adds a default router without setting that
lifetime properly, the expiration time provokes a bad crash of the kernel.

I hope I captured all comments from the pdf.

I will update the draft soon.  Please reply to this email letting know
whether you agree with this, or how you see the updates to the draft.

Yours,

Alex