Subject: RE: [dhcwg] Interface

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 18 Sep 2001 14:50:59 -0500

The client *MUST* send the messages through the interface being configured. The client uses multicast messages and if directly received by the server, that's the way it knows what link the client is on. If a relay receives it and forwards it, that's how it can tag the message having come from that link so that the server knows what link the client is on. If the server doesn't know the correct link, it can't assign the proper addresses.

Note however that I feel if a server had told the client it may use unicast and the client has addresses of sufficient scope, there is no reason why the client must use that interface. This requires that client's source address is one of the addresses for that interface that is of "value" to the server in identifying the correct link. For example, a globally unique address would likely be of sufficient scope.

- Bernie

-----Original Message-----
From: Guja, ArturX [mailto:[email-masked]]
Sent: Tuesday, September 18, 2001 3:33 PM
To: [email-masked]
Subject: [dhcwg] Interface

Sorry for posting so many questions, but I'm working overtime on my
diploma here. I'm really grateful for any input.

So another one:
Is the client required to send DHCPv6 messages through the interface it is
going to configure, or can it send them through any interface?
I mean, why should there be such a restriction? After all, it sends
the DUID and the link-local address in the message. It might as well
use ANY interface for communication with the server, eg. when it is
multi-homed, and there is a DHCP server available on only one link,
but it serves the whole net :)))

I know it was mentioned somewhere, but I can't find it. :)))
Soory to bother you :)))

Artur

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 19 Sep 2001 11:50:02 +0200 (CEST)

> The client *MUST* send the messages through the interface being configured.
> The client uses multicast messages and if directly received by the server,
> that's the way it knows what link the client is on. If a relay receives it
> and forwards it, that's how it can tag the message having come from that
> link so that the server knows what link the client is on. If the server
> doesn't know the correct link, it can't assign the proper addresses.

Bernie,

I suspect that the real constraint is that the client MUST send the
message on an interface attached to the same *LINK* as the interface it
is trying to configure. When the client has multiple interfaces attached to
the same link the server/relay can't tell which one was used (short of
inspecting the source MAC address which may or may not differ).

If the document will cover this distinction it would make sense to
add a reference to draft-ietf-ipngwg-scoping-arch-02.txt.

   Erik

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Sep 2001 09:37:18 -0700

> inspecting the source MAC address which may or may not differ).

How does the client know that two interfaces are attached to the same
link?   Better to leave well enough alone.

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Sep 2001 10:18:00 +0200 (CEST)

> link?   Better to leave well enough alone.

I suspect IEEE 802.3ad could tell the client such a fact. Of course one
could view 802.3ad as providing a single interface to IP, but the scoped
address architecture does include the ability of having IP "see" multiple
interfaces to the same link.

But that's beside the point - which is to not overconstrain the spec 
with MUSTs that aren't quite true.

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Sep 2001 08:41:38 -0700

> with MUSTs that aren't quite true.

The point is to come up with a working, implementable protocol
definition, that does not only work if you happen to be running
802.3ad in a certain obscure implementation.

Most implementors will not run into the corner case you've just
described, but those same implementors have a pretty good chance of
producing a non-interoperable client implementation if that MUST isn't
there.  In the corner case you've described, unless I am very much
mistaken, the MUST will _not_ cause a problem.  So the MUST should
stay.

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Sep 2001 19:11:37 +0200 (CEST)

> 802.3ad in a certain obscure implementation.

Ted,

the tone of your statement reads like an attack on a particular unnamed 
implementation.  I certainly did not describe an existing implementation -
in fact I have no idea whether there exists an IEEE 802.3ad that does what
I described. (And the whole mention about implementation was in response to
a question whether there was an automatic way for hosts to determine that
multiple interfaces are connected to the same link.) Sigh :-(

What I did point out is that the IPv6 architecture allows multiple interfaces
connected to the same link. That is the real issue.

> mistaken, the MUST will _not_ cause a problem.  So the MUST should

I don't think MUSTs are intended to prescribe rules for a subset of
the implementations - their original use was to describe (often subtle)
things that implementors had overlooked in the past that caused rather bad
things to the network (such a broadcast storms).
Today MUSTs are used to make firm statements for behavior
that applies to all implementations.

So you seem to be describing a case where a SHOULD applies. RFC 2119:
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Alternatively text along the lines of this makes sense
	"... MUST (unless where the client has multiple interfaces connected to
	the same link [SCOPING-ARCH] in which case the ... MUST be for one
	of the interfaces connected to the same link) ..."

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Sep 2001 22:24:57 -0700

I don't know what to say, Erik.   It feels to me like you are trying
to open the protocol to breakage in order to be pedantic.   What
matters to me is not the precise wording of RFC2119, but rather
whether or not the protocol specification we arrive at will result in
interoperable implementations.

If we turn this particular MUST into a SHOULD, I promise you that
there will be interoperability problems.  I speak on the basis of a
wealth of personal experience with DHCP client implementations.

I argued with you about the particulars because you gave IEEE802.3ad
as an example of why we need to change this MUST into a SHOULD, and it
was not a valid example.   So I would really appreciate it if we could
keep this as a MUST.

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Sep 2001 10:26:56 +0200 (CEST)

> wealth of personal experience with DHCP client implementations.

OK - I sense the equivalent of grade inflation here caused by presumed clueless
implementors. Need to update RFC 2119 with the "REALLY MUST" and "REALLY MUST
NOT" to deal with this :-) :-)

> was not a valid example.   So I would really appreciate it if we could

No, I did NOT! Please re-read the email thread.
The reason for changing it (or clarifying the constraint) was
draft-ietf-ipngwg-scoping-arch-02.txt.

But I haven't read what the actual text says so this might all be a red
herring. I responded to an email which had an explanation which essentially
said (with significant ad-libbing)
	MUST send on that interface since otherwise the agent will be
	confused.
This statement is incorrect.
But if the statement is instead
	MUST send on that interface to ensure that the packet is guaranteed
	to appear on the correct link (*). If the message appears on the wrong
	link the agent will be confused.
	*) This ensures that the packet arrives on the correct link even
	in the case when a node has multiple interfaces on the same link
	but has incorrect information about which interfaces connect to
	which links.
I think the footnote can be omitted - but it might help future readers to
understand the background.

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Sep 2001 09:10:09 -0700

> OK - I sense the equivalent of grade inflation here caused by
> presumed clueless implementors. Need to update RFC 2119 with the
> "REALLY MUST" and "REALLY MUST NOT" to deal with this :-) :-)

*grin*    I think there's some truth to it, but you're making it out to
 be worse than it is.

> No, I did NOT! Please re-read the email thread.

Oops, sorry.

> This statement is incorrect.

Okay, I'll buy that.

> understand the background.

This wording works for me (I'll let Ralph decide about the footnote).
Thanks for continuing to beat me up about this!  :'}

			       _MelloN_

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 25 Sep 2001 21:43:14 -0700 (PDT)

WG last call comments on draft-aboba-dhc-domsearch-05.txt have been
incorporated into draft-aboba-dhc-domsearch-06.txt, which is now on the
IETF archive. 

Now that these comments have been incorporated, I believe that this
document is ready for IETF last call.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Sep 2001 07:02:07 -0400

> document is ready for IETF last call.

I'll wait for Ralph to signal that the document is ready, but here are
my comments.

Main item is that it has a normative reference to

> [7]  Lemon, T., "Encoding Long DHCP Options", Internet draft (work in
>      progress), draft-ietf-dhc-concat-01.txt, July 2001.

so these two document should go together.

Some minor wording nits (these can be dealt with later):

> the domain search list.  This document defines a new DHCP option which
> is passed from the DHCP Server to the DHCP Client to specify the domain
> search list when resolving hostnames.

Is the option allowed to be included in client messages? I would
assume so. Indeed, isn't it the case that clients can include any
option if to signal a desire to the server to get such an option
returned? If so, I guess this isn't really an issue.

> In this scheme, an entire domain name or a  list of labels at the end of
> a domain name is replaced with a pointer to a prior occurrence of the

s/is replaced/can be replaced/

> same name.  Despite its complexity, this technique is valuable since the

Thomas

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Sep 2001 07:00:14 -0700 (PDT)

> so these two document should go together.

Not sure the reference is normative. This option can use the long option
encoding if available, but doesn't require it. 

> returned? If so, I guess this isn't really an issue.

Yes, that's my understanding.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Sep 2001 13:45:25 -0400

My comments are in line...

- Ralph

>encoding if available, but doesn't require it.

Agreed; in fact, I think you could eliminate references to
the long option encoding draft w/o harming your spec...

>Yes, that's my understanding.

Perhaps it would be easiest to change the sentence to: This document
defines a new DHCP option that specifies the domain search list
to be used by a DHCP client when resolving hostnames.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Sep 2001 14:40:54 -0400

> the long option encoding draft w/o harming your spec...

This make sense to me. I will note, however, that current wording in
the concat draft could be interpret to suggest that it's intended for
future options and maybe less so for existing options. If the intent
is in fact that it the concat draft should apply to *all* DHCP
options, then taking out the reference would be fine.

If that is the intent, I'll go ahead and start the IETF last call on
domsearch.

Thomas

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Sep 2001 11:55:03 -0700 (PDT)

> If that is the intent, I'll go ahead and start the IETF last call on

I had thought that concat would apply to all DHCP options that could
potentially run over the current limit.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Sep 2001 15:26:15 -0400

RFC2131 allows for options that can carry
data values longer than 255 bytes, so my understanding,
too, is that the option concatenation standard would
apply to all DHCP options.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2001 12:38:43 -0700

> >      progress), draft-ietf-dhc-concat-01.txt, July 2001.

We're in last call on the concat option as well, and I have a new
version with some changes suggested by Stuart Cheshire.   I think it's
ready to go.   So I'll publish it now.

> returned? If so, I guess this isn't really an issue.

It doesn't make sense to include this in a client message, but the
draft isn't saying a server should drop a message that contains this
option, so I think this is a non-issue.

> s/is replaced/can be replaced/

The wording only applies if you are doing compression, so the definite
form of the verb is correct, and the indefinite form would be less
correct, IMHO.

			       _MelloN_