Subject: [dhcwg] future-proofing?

From: "David W. Hankins" <[email-masked]>
Date: Wed, 3 Oct 2007 09:57:32 -0700

I just made some changes to our handling of Confirm messages 10
seconds ago and had a thought;

RFC3315 section 18.2.2 ("Receipt of Confirm Messages") only refers to
"IA"s.  Of course what it means is that the server needs to look
through all IA_NA's and IA_TA's (wether it offers IA_TA's itself or
not).

In the future, it is possible (if improbable) that there will be a
third kind of "addressing" IA that will need Confirm support.  Let's
call it IA_NG for brevity.

If the clients only supply IA_NG's, then there is no problem - the
18.2.2 guidance is to ignore these packets.  If there are no IA_NA or
IA_TA's, or at least if they do not have IAADDR's in them, then in
18.2.2 the servers are directed not to reply.  Ostensibly IA_NG
supporting servers will reply.

If the client supplies a mixture of IA_NA, IA_TA, and IA_NG, then
we have a potential problem.

If the client has just one appropriate address in an IA_NA or IA_TA,
then the server "sort of assumes" that the IA_NG's addresses are
all appropriate...because it doesn't know to check.

Now, I postulate that it is probably uncommon to find a situation
where IA_NA/IA_TA addresses are appropriate and where the IA_NG
addresses are not.  That is, they're probably all under the same
prefixes, and those prefixes probably aren't configured in multiple
separate broadcast domains...or if they are, not inconsistently?

So it's probably a safe bet.

But I think it's still a bet.

Should there be a mandatory client-supplied option-list-option that
specifies which options it sent are IA_*'s "requiring validation all
together", so that servers without "IA_NG" support can be mandated to
remain silent?

Or something else...?

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Oct 2007 08:25:12 -0400

>together", so that servers without "IA_NG" support can be mandated to

I think a better option would be to have the server indicate which
IA_*'s it processed when making the on/off-line determination. That
might provide the client with the ability to make a decision. For
example, if it got a not-on-link for the IA_NA IAADDRs provided, that
would indicate that the client is not on that link.

There might also be cases where we have IA_NG and IA_NG1 and one server
supports IA_NG and another IA_NG1, thus if the client gets on-link
notification from both those servers for IA_NG and IA_NG1 respectively,
it can consider itself on-link.

I vaguely recall that this issue was discussed when the CONFIRM message
was developed, but we didn't consider it critical at the time to develop
such a mechanism.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Wednesday, October 03, 2007 12:58 PM
To: [email-masked]
Subject: [dhcwg] future-proofing?

Or something else...?

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 4 Oct 2007 11:47:23 -0700

> would indicate that the client is not on that link.

That's a good idea.

> was developed, but we didn't consider it critical at the time to develop

I think that's correct; we can introduce the new server->client option
if and when a new IA is developed; the client that newly supports the
new IA can easily support validation of the server option.