Subject: Re: DHCPv6 Input from Francis Dupont

From: Francis Dupont <[email-masked]>
Date: Thu, 9 Dec 1999 05:29:37 -0500 (EST)

In your previous mail you wrote:

   >  - I prefer to have a 32 bit interface index (relative to the agent)
   >    in place of the agent address + prefix-size. I am not convinced
   >    address + prefix-size is enough for all topologies, an interface index
   >    is clearer and easier to use (as a scope ID). This solves the alignement
   >    problem to if link-local addresses are replaced by interface index +
   >    link-local address.
   
   If we go the above path this implies that a client will be identified
   by the ifindex on the relay plus the client's link-local address.

=> there are two different problems:
 - how the server identifies the client (and should the server recognize
   a client using a different relay?)
 - how the relay gets the link to use in a packet from a server.
My concern is for the second problem the only good solution is to have
the interface index because a naked address is not enough.

   >  - the real source of the problem is in RFC 2462 5.5.3 "Router
   >    Advertisement Processing" page 17 where you can find after two paragraphs
   >    about M (managed) and O (other) bits this statement:
   >    "For each Prefix-Information option in the Router Advertisement: a-e)"
   >    obviously the text after this statement and the 5.6 "Configuration
   >    Consistency" section next page (with "hosts accept the union of all
   >    information ..." are misleading in the stateful autoconf context.
   
   What is misleading?

=> the case where the M bit and A flags are set was not clear for me
then I propose to clarify this with a statement explaining that
when the M bit is set then A flags should not be set.
(of course this statement can go into a DHCPv6 document)

   But isn't "stateless mode is available" the same as "one or more prefixes
   have the A bit set"?

=> yes

   Thus I think we already have the necessary knobs.
   
=> I agree, we should only clarify this point in a DHCPv6 document.

Thanks

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 9 Dec 1999 06:00:15 -0500 (EST)

In your previous mail you wrote:

   >*If* we agree that a client should be identified as the same client
   >by a server independent of the relay agent it is using on the link
   >then I think the spec needs a slight tweak.
   
   I think we all agreed long ago that a client needs to be identified as
   you very nicely stated, if anyone does not agree I would be surprised.
   
=> then the answer is yes and we should check if the current proposal
covers all the cases...

   >It currently says that the client is identified by <link-local address,
   >agent-address> and I think this should be <link-local address, agent-prefix>.
   >(where agent-prefix could also be called link-prefix since it is the prefix of
   >the client's link that matters).
   
   It should say agent-prefix that was a typo in draft-14 for some reason,
   the authors agree with you, and there are other places where we speak of
   prefix for sure, but this is an edit error in the spec presently.
   
=> the use of the prefix-size was a recurrent weakness of draft-XX.
I hope this discussion will give a better I-D... (:-)

   >In addition to clarifying the scope (site-local vs. global) for
   >the agent-prefix as you point out we also need to make sure that
   >two agents on a link pick the same prefix as agent-prefix,
   >since there can be multiple global prefixes assigned to the link.
   >I think some simple rules (pick the numerically largest prefix)
   >would suffice.
   
   I agree.  We need to add that and the scope issue.
   
=> I believe we have an issue for "off-link" prefixes too because
they are by definition shared between links ?!

Regards

[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 9 Dec 1999 17:05:02 -0500 (EST)

> the interface index because a naked address is not enough.

Agreed that ifindex would work for the 2nd problem. 
I thought you were talking about the 1st problem.

   Erik