Subject: [rfc2462bis] whether we need the M/O flags

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 15 Apr 2004 20:40:14 +0900

As I just said in a separate message, one big question had been raised
about rfc2462bis.  It was, in my understanding, 

  whether we need the M/O flags for the "stateful" protocol(s) in the
  first place.

(Actually, different people used different representation related to
this issue, but, in my understanding, we can simply summarize the
essential part of the question as above).

I know this is probably highly controversial, but I tend to agree on
removing (or deprecating) these bits.

The main reasons have already been shown in the thread starting at the
following URL:
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg02262.html

One additional point is that I'm not sure if we can really recycle
rfc2462bis as a draft standard with keeping these bits.  If we keep
them, we'll probably need to find running implementations regarding
these bits that are interoperable.  (If so) can we really make it
soon?  As far as I know, no host implementation supports the M flag.
Regarding the O flag, I've implemented the host side of the flag,
which invokes a DHCPv6 client upon receiving an RA with the O bit.
But I've never heard of other implementations.

This also means one obvious problem when we remove these bits is
actually a non-issue.  That is, we do not have to worry about the
problem that we may make serious loss of compatibility.

Another possible disadvantage is that we'll lose the ability to
trigger DHCPv6 (or, if you like a general wording, trigger a stateful
protocol).  I admit this can be a problem.  A rough idea to deal with
this is to provide a different, more general way to provide the
ability as a separate document.  For example, a separate ND option
which can trigger a particular protocol (including DHCPv6) for a
particular purpose (e.g., to get "additional" configuration
information) might make sense to implement the idea.  In fact, an
extension to ND to re-invoke a protocol for "other information" has
already been proposed: draft-vijay-ipv6-icmp-refresh-otherconf-00.txt.

I know this is probably too radical to make a concrete proposal at
this stage, but if we can really agree on the basic idea of this path,
I'd probably do the followings in rfc2462:

- remove all references to "stateful" protocols
- deprecate the M and O flags, that is,
   + reserve the fields and clarify that they must not be used
     (this may affect rfc2461bis, too)
   + remove all the usages regarding these flags

Any comments/suggestions/objections are welcome.  Thanks in advance,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ralph Droms <[email-masked]>
Date: Thu, 15 Apr 2004 12:25:46 -0400

At 08:40 PM 4/15/2004 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>[...] As far as I know, no host implementation supports the M flag.

Here's another data point: The Cisco IPv6 stack implements the host behavior
for the O bit, initiating an Information-request exchange when an RA with
the O bit set causes OtherConfigFlag to change from FALSE to TRUE.  The
stack ignores the M bit because there is no code for DHCPv6 address
assignment.  The RA code in the Cisco stack can be configured to send RAs
with the M and O bits cleared or set.

- Ralph

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Apr 2004 10:14:41 -0700

I think that deprecating the O & M bits will be good.
I'm not too worried about incompatibility, as most code
do not support those bits anyway. Also, it is mostly an
operational issue. All we need to do is to publish
a BCP saying essentially: "Do  not set the O & M bits in RA"
and we are done.

In terms of harm, I think leaving O & M is harmful, as it keeps 
confusing people.
A good design is not one where there is no extra feature to remove,
not one where there is no new feature to add.

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Apr 2004 10:38:03 -0700

This of course should read:

> A good design is one where there is no extra feature to remove,

Sorry for the confusion.

	- Alain.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 24 Apr 2004 00:05:40 +0900

>>>>> On Thu, 15 Apr 2004 20:40:14 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> removing (or deprecating) these bits.

(Note: In this message, I'm basically speaking just as an individual
in this list.  I'll propose an action as a 2462bis editor after the
entire discussion; it may or may not be same as what I'm going to say
below)

(Another note: this is a long message, sorry about it.  But I hope all
who are interested in this topic will read the entire message and
comment it.)

Thanks for all the input.  Going through the thread so far, I've been
thinking about this issue closer...and, I personally still have the
same opinion.

Some people commented that we needed to clarify what's bad with the
M/O flags if we want to deprecate (or remove) them.  That's a fair
comment.  My points are as follows (some of which have already been
shown in the thread):

- the lack of interoperable implementation (or the fact that there are
  very few implementations) regarding the flags, at the host side
  particularly, will probably be a barrier to recycle the document as
  a DS.  From my honest impression on Section 4.1.2 of RFC2026, even
  2462 should have not become a DS document.  I've still not heard why
  they could make it at that time, so I know I may be wrong.

- each flag can only convey information of a single-bit, causing
  several problems:
  + we'd need to specify a single protocol corresponding to each flag
    in order to avoid combination mess and interoperability problems.
    For the M flag, it's probably okay, because we seem to have agreed
    on the protocol is DHCPv6 (RFC3315).  For the O flag, however, I'm
    not sure if the situation is mature enough.  Stateless DHCPv6
    (RFC3736) is likely to be a candidate (and I'd personally take
    it), but can we really agree on it?  Aren't there other
    possibilities?  For example, the full DHCPv6 protocol (RFC3315)
    can also work as the protocol for the O flag.  Others may want to
    propose non DHCPv6 protocols like SLP...then, are we really sure
    we won't want to introduce flexibility by a separate mechanism
    allowing a particular protocol?

  + there is no way to turn off the use of "stateful" protocols.
    (Note that changing the flag from set to clear does not mean
     turning off the protocol)

  + if we adopt stateless DHCPv6 as the protocol for the O flag, we'll
    need a separate trick to handle renumbering events, e.g., as
    proposed in draft-vijay-ipv6-icmp-refresh-otherconf-00.txt.  Of
    course, we'd probably be able to separate this as a future
    extension, but then why can't we reconsider the purpose of the O
    flag from the beginning?  (If you're going to say "because it
    will break existing work", please see below first).

Now let's think about cons of deprecating these flags.

The obvious one is that this action may break existing
implementations.  In fact, this is the most typical objection I've
seen in this thread.

To discuss this point precisely, I'd fist like to talk about the host
side.  That is, implementations that

  A. invoke some "stateful" protocol on the reception of an RA with the
     M flag being set
  B. invoke some "stateful" protocol on the reception of an RA with the
     O flag being set

As far as I know, there is no type-A implementation.  And, as far as I
know, there are only two type-B implementations: Cisco's host
implementation, and the one implemented by KAME (that I myself wrote):
both of them (can) invoke an RFC3736 client in this case.

I don't know how Cisco would feel if the O flag were deprecated.
Perhaps Ralph can comment on it.  If they strongly want to keep this
flag, of course it will be a strong reason to do so.

Regarding KAME's implementation, at least the implementor (myself) is
okay to deprecate the flags.  Also, it's just an experimental
implementation to identify issues, so this feature (invoking an
RFC3736 client) is disabled by default in the implementation and is
not officially released in the BSD community.  In fact, I'm tempted to
deprecate the flags based on my experiments with the implementation,
identifying the issues described above.

Of course, as someone said in the thread, this does not mean there are
no implementors who have an implementation that would be broken by
deprecating the flags and thus would complain about it.  However, I'd
respectfully say this argument is unfair, considering the scale of
this mailing list and the number of participants in this particular
thread.  Actually, (at least) 7 people from different organizations
have commented, and none of them could show concrete examples except
the above two.  In general, it is hard to prove the non-existence of
something, and I think it's almost impossible in this kind of topic
(you could always say "someone in an isolated island only with
computers and RFCs might have implemented this feature" - no one can
refute this argument).

For me, the discussion so far indicates there is actually nothing
broken by deprecating the flags in a practical sense (believe me, I'm
trying to be fair in this sentence), as long as Cisco is okay for
their host side implementation.  Regarding the Cisco case, I'd like to
hear from Ralph about his opinion.

Meanwhile, please do not forget the original specification in RFC2462
was very unclear about these flags, which might break something if we
want to clarify the behavior, even keeping the flags.  For example, it
even does not specify a particular protocol (at least not clearly) to
be invoked by the flags.  So, what if someone has a host side
implementation that invokes a proprietary "stateful" protocol upon
receiving the M flag and claims "my implementation perfectly working
under RFC2462 will be broken if you specify DHCPv6 as the 'stateful'
protocol".  Can this be a reason for not making the specification
clear on this?  I hope not, and if we can agree on this point, then it
seems to me that this discussion shows that the current specification
is too unclear to worry about breaking "something" working so far with
it.

So far, I've discussed the host case.  Let's move on to the router
case.

Yes, there are many router implementations that have the ability to
set the M/O flags.  However, as long as we can agree on deprecating
the flags from hosts's point of view (as discussed so far), I believe
we can still deprecate the flags without breaking implementations.

In fact, setting these flags at the router has had no effects so far
in a practical sense.  So, nothing in the router implementations will
be broken unless we reuse these bits for different purposes.

Now, I've dumped what I have.  Hopefully I've made several things
clear.  Still, I expect different opinions (actually, I still expect
objections).  So, please speak up.

I'd particularly want to have a *concrete* counter example that will
be broken with the deprecation (not just "*something* that might have
been working well and will be broken").  Also, I'd really like to know
if the lack of interoperable implementation can be an issue or not.

I'm going to wear a hat of 2462bis editor, collecting opinions again,
and would like to make a concrete proposal next week based on the
result.

Thanks,

					JINMEI, Tatuya

---

From: Alain Durand <[email-masked]>
Date: Fri, 23 Apr 2004 11:19:04 -0700

Jinmei,

I agree with your analysis, except that I'm not so much worried about
breaking somebody's assumption in designing an hypothetical client
dealing with the O/M bits. The definition of those bits was obscure
in 2462 anyway.
I would be more worried if this was to result in demonstrated 
operational
problems. I honestly believe that there won't be any as deprecating O & 
M
will end up being equivalent to today's most common practice where
those bits are not set. Nothing breaks today under those circumstances,
so I do not see what should break tomorrow if we were to deprecate 
those 2 bits!

Of course, if someone could point to a real case scenario where
this would be a problem, that could change my opinion...

	- Alain.

---

From: "Russell Brian" <[email-masked]>
Date: Fri, 23 Apr 2004 12:38:08 -0700

Hello,

We have actually designed a large-scale system making use of the M flag as
it was a large part of RFC 2462 and we were not aware that IETF would be
considering deprecating it.  Please take this into consideration in your
discussions.

Regards,

Brian Russell
Systems Engineer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Alain
Durand
Sent: Friday, April 23, 2004 11:19 AM
To: JINMEI Tatuya / ?_-?'B?A
Cc: [email-masked]
Subject: Re: [rfc2462bis] whether we need the M/O flags

Jinmei,

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 23 Apr 2004 12:59:44 -0700

Brian,

Could you provide more details? Which host implementation are you
using?

	- Alain.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 23 Apr 2004 23:24:19 +0200

On 23-apr-04, at 17:05, JINMEI Tatuya / 神明達哉 wrote:

> M/O flags if we want to deprecate (or remove) them.

You only discuss "what would break if we deprecate these flags". I have 
no problems with the text that follows, but I DO have a very big 
problem with changing these flags. You can't just go around and change 
protocol specifications every few years just because it looks better 
that way.

Besides, NOW is certainly not the time to do it, as DHCPv6 is finally 
there, but hasn't seen much if any real-life experience yet, and 
additional "other configuration" mechanisms are still under discussion 
for at least one very important configuration item: recursive DNS 
server addresses.

I implore this wg to venture out into the real world and ask operators 
what they need to be able to use IPv6 rather than regurgitate the same 
RFCs over and over. This goes double for v6ops.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sat, 24 Apr 2004 14:46:45 +0900

>>>>> On Fri, 23 Apr 2004 23:24:19 +0200, 
>>>>> Iljitsch van Beijnum <[email-masked]> said:

> protocol specifications every few years just because it looks better 

Sorry, I don't understand the comment...I still have a feeling that I
see an attempt to impose a negative impression on a concrete proposal
based on a practical analysis by making a general comment that no one
can disagree.

It's probably true that "you (we) can't just go around and change
protocol specifications every few years just because it looks better,"
but how does this apply to my proposal?

I tried to describe what is wrong with the current specification,
tried to describe what can be broken by deprecating the flags, and
tried to explain the breakage won't be a problem in a practical sense
(at least IMO).  If this discussion is convincing but still can be
regarded as "just saying it looks better that way", can't we ever
deprecate anything?  For example, if we can buy this kind of argument,
how could we deprecate site-local addresses?

Also, what do you mean by "every few years" in this particular
discussion?  RFC2462 was published in 1998, and we are now trying to
make the specification clearer, fixing known problems and clarifying
the details based on 5-6 years of experience.  Are you saying this
activity as "changing protocol specifications every few years"?

Honestly, I'm willing to withdraw the proposal if someone makes a
concrete, convincing couter argument...but, yours seems too
general, abstract, and unfair (sorry, I can't find a better word) to
convince me on this particular topic.

(But I don't think this paragraph is your main point, and if I'm
correct, let's just focus on the rest of your message)

> for at least one very important configuration item: recursive DNS 

So are you proposing to keep the flags but leave the semantics (e.g.,
what the "stateful" protocol is) unclear as currently is?  If so, I
disagree for two reasons.

First, it will easily cause confusion and interoperability problems to
leave it unclear.  In fact, we have seen the confusion due to the
unclear specification since RFC2462 (or even since RFC1970), and this
is exactly the reason why we are now trying to clarify this point.

Secondly, if the situation is that immature, why can't we simply
deprecate the flags for now and leave the flexibility for future
extension?  This way, we can clearly avoid confusion due to the
unclear specification and the misuse of the flags based on the
confusion, as well as leave the possibility to adopt the best way as
the situation becomes mature.  We'll even be able to revive the same
flags at that time.

> RFCs over and over. This goes double for v6ops.

A general comment, again...so what exactly are you proposing for this
particular issue?  Even though main subscribers in this list are
implementors, I'm quite sure that we also have many operators here.
In fact, I'm running IPv6 networks of my own.  I also know operators
working for major ISPs subscribe to this list.  And I'm asking
everyone in this list, including operators of course, on this issue.
If you're requiring to bring this discussion to the v6ops wg and ask
them what they think, that's fine.  But I'm quite sure many vocal
members there subscribe to this list as well.

					JINMEI, Tatuya

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 Apr 2004 11:23:39 +0200

> based on a practical analysis by making a general comment that no one

I apologize for the negativity. However, when I first got involved with 
the IETF not all that long ago, I was shocked to learn how much work is 
(still) going on on so many aspects of IPv6. I have since then learned 
that a good deal of this work is very necessary, but I still also 
believe that a lot of it isn't.

The very first question I ask myself whenever I read an a draft or a 
proposal that changes something is: "what would go horribly wrong 
without this change?" If the answer is "nothing" this means we should 
probably not make the change, since even the slightest change 
introduces very real costs with regard to modifying code, testing and 
training. Remember that nothing ever dies on the web. There are still 
people who think the flow label is 24 bits because the documents that 
say this is are still online and indexed by Google.

> but how does this apply to my proposal?

Your text makes a good case that there won't be any implementation 
problems by removing the bits. However, you don't really explain why it 
is a good idea to do so. (Or I must have overlooked it.)

> If this discussion is convincing but still can be

This is different, as we've determined that there are serious problems 
with the use of site locals. But how about the change from ip6.int to 
ip6.arpa. I wasn't there when this was decided, but whatever the 
rationale, I have a very hard time believing it was worth the confusion 
and operational problems that were caused.

> is exactly the reason why we are now trying to clarify this point.

Can you elaborate? I agree that some confusion is possible, but since 
there are many interoperable implementations, I don't see how this can 
lead to real-world problems.

> extension?

Good question.

I believe that some information in RAs that guides the discovery and 
configuration process is probably necessary in the future. We have 
these two bits now. Suppose we remove them from the spec, and then in a 
few years we really know what we need and introduce a new, better 
mechanism. This gives us nine combinations of implementations to worry 
about: hosts according to RFC 2462, 2462bis and 2462ter on the one 
hand, and routes according to RFC 2462, 2462bis and 2462ter on the 
other hand. Worse, we probably have to support at least coexistance of 
hosts with different implementations on the same link at the same time 
for a significant number of years.

Now consider the situation where we don't change the bits right now but 
they are changed at some point in the future. This only gives us four 
combinations to worry about: old host + old router, old host + new 
router, new host + old router and new host + new router. That's less 
than half the combinations. Also, if we are to change the bits, new 
implementations would still have to recognize them to be backward 
compatible so the change doesn't make any difference to code that is 
cut any time soon.

Now lets focus our attention on what we want to accomplish 
operationally.

In theory, the bits aren't necessary as we can simply always do RA and 
DHCP and see which one succeeds. The network operator can then decide 
to either turn on RAs, turn on DHCP or do both. However, there are two 
problems with this:

- For other configuration, waiting for a DHCP reply that isn't 
forthcoming wastes time. Having the O flag mean "don't bother with 
stateful other configuration as it isn't going to succeed anyway" would 
be beneficial here. (For instance, if a host needs to look up a name 
and any statically configured DNS resolvers (well known or otherwise) 
may or may not be reachable, and a DHCP server may or may not be 
available. So if the host does the DNS request using the statically 
configured DNS it may incur a timeout, but if it first tries to 
configure DNS resolvers through DHCP it may also incur a timeout. The O 
flag can provide guidance in this case.)

- A network operator may prefer that hosts use DHCP for address 
configuration. However, turning off RAs is probably infeasible because 
there may be hosts that don't support DHCP. So if we take the M flag to 
mean "don't do stateless autoconfiguration unless stateful 
configuration fails" the operator gets to support hosts that don't 
support DHCP while at the same time avoiding that hosts that do support 
it use RA-based addresses.

In other words:

M = 0, O = 0: Do stateless address configuration and start to 
communicate.
               If DHCP is done, it's in the background. DHCP complements
               static and RA other configuration.
M = 0, O = 1: Do stateless address configuration and complete DHCP 
before
               initiating communication that requires other 
configuration.
               DHCP overwrites static and RA other configuration.
M = 1, O = 0: Do DHCP. If DHCP succeeds, don't do stateless address
               configuration. Start to communicate after DHCP succeeds or
               after DHCP fails and stateless address configuration
               succeeds. Static and RA other configuration complement 
DHCP.
M = 1, O = 1: Do DHCP. If DHCP succeeds, don't do stateless address
               configuration. Start to communicate after DHCP succeeds or
               after DHCP fails and stateless address configuration
               succeeds. DHCP overwrites static and RA other 
configuration.

Where "complements" means that information is added to other 
configuration information, but with a lower priority. For instance, if 
with M = 0, O = 0 resolv.conf has the address 192.0.2.1 and DHCP 
supplies 240.240.240.240, the list becomes "192.0.2.1, 240.240.240.240" 
in that order. "Overwrites" means that old information is replaced when 
the other protocol supplies information of the same type. So if 
192.0.2.1 is present and the new information is 240.240.240.240 the 
result is just "240.240.240.240". However, if no replacement DNS 
resolvers were supplied 192.0.2.1 would continue to be used.

(RA other configuration listed for completeness.)

I don't have a problem with the fact that DHCPv6 isn't explicitly made 
the stateful protocol that the existing RFCs talk about. It should be 
the default one, but some networks may prefer to use something other 
than DHCP for this. I'm just saying "DHCP" above to save myself some 
typing.

> This way, we can clearly avoid confusion due to the
> confusion,

I agree that the current specs aren't as clear as they could (and 
possibly should) be. But I think it's better to leave the bits as they 
are and describe what they do or should do more clearly than removing 
them.

> working for major ISPs subscribe to this list.

If you compare the various IPv6-related lists (this one, v6ops and even 
dnsops) with interdomain routing related ones such as grow and even 
idr, it is apparent that most of the focus with IPv6 is on building 
specifications based on theoretical considerations. I see very little 
operational feedback. This is especially apparent with regard to the 
DNS configuration issue.

> them what they think, that's fine.

No, I don't think that will make a difference.

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Mon, 26 Apr 2004 10:28:16 +0200

> entire discussion; it may or may not be same as what I'm going to say
I think your approach to look at the two sides of the medal is very
useful, but I don't find either argument (pro & con) very convincing at
this particular point of time.

However, what I can clearly read from the discussion is that the
definition of the use / function of the M/O bits needs an update.
Including a reference to existing protocols would be useful to explain
the use of the flags, for example.

I would like to remind you that for example many DHCPv6 implementations
are quite young and still need to evolve in terms of functionality (that
includes the use of M/O bits). It would be great if we could postpone
the discussion to a later time when we can actually see if those
implementation can make use of the M/O bits in a way that makes sense.
As the development of the implementation progresses, I'm sure that the
number of scenarios where M/O bits are useful will increase.

Baseline is, it would be good to postpone the deprecation discussion and
at the same time update the definition of the use of the M/O bits. I can
think of scenarios where M/O is useful but the mental picture of these
is not clear enough yet to really make a point. Deciding upon
deprecation or not would be premature at this point of time, IMHO.

Cheers,
Christian 
-- 
JOIN - IP Version 6 in the WiN  Christian Strauf
A DFN project                   Westfälische Wilhelms-Universität Münster
http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung
Team: [email-masked]      Röntgenstrasse 9-13
Priv: [email-masked]    D-48149 Münster / Germany
GPG-/PGP-Key-ID: 1DFAAA9A       Fon: +49 251 83 31639, Fax: +49 251 83 31653

---

From: Alain Durand <[email-masked]>
Date: Mon, 26 Apr 2004 10:14:02 -0700

Let me try to explain why I, as an implementor, do not like the M/O 
bits very much.

It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
an automatic and insecure way to trigger an external configuration 
mechanism.

The are security implication for the hosts in implementing those bits.
They are received in RA, which are mostly insecure (anyone can send a 
"valid" RA)
The current text says a host should turn stateful autoconf when 
receiving those bits.
So one could mount an attack fairly easily by introducing a rogue DHCPv6
server on a network that had no DHCPv6 so far and send a fake RA with
the M/O bits on. The host will then configure itself using data coming
from the new rogue DHCPv6 server.

2462 says "host should invoke the stateful address autoconfiguration 
protocol"
and not "MUST invoke", so there are already provision for not obeying
the M/O bits. But if those bits are not mandatory to execute, why are 
they here in
the first place? To give a hint that DHCPv6 is present?
Host should not blindly believe this unless the RA are secured.
Also, there are no such bits in IPv4, and host implementations that 
chose to turn
DHCPv4 on simply try it. Why is is not good for IPv6?

	- Alain.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Apr 2004 22:10:27 +0200

> an automatic and insecure way to trigger an external configuration 

So you object to the security level of DHCPv6 rather than that of the M 
and O bits?

> from the new rogue DHCPv6 server.

So what is the alternative? If there are no M and O bits, people 
implementing DHCPv6 will have to perform DHCP *always* so there is no 
protection against a rogue DHCPv6 server over the situation you 
describe.

If you want people to enable DHCPv6 manually: ok, no problem. But why 
would the M and O bits be in the way in that case? Just ignore them.

> they here in the first place?

Maybe because the IETF has no business to tell people in which way they 
should run their network, but only to provide them guidance on how a 
certain task can be performed in an interoperable way IF and WHEN the 
operator decides they want this task to be performed in the first 
place.

> To give a hint that DHCPv6 is present?

Don't you consider this useful?

> Host should not blindly believe this unless the RA are secured.

So what kind of bad stuff is going to happen when hosts start querying 
a rogue DHCPv6 server? I think the main problem is that traffic can be 
redirected through a rogue router which then has the opportunity to 
perform man in the middle attacks. However, the rogue system can just 
as easily perform the same thing using just RAs.

> chose to turn DHCPv4 on simply try it. Why is is not good for IPv6?

The difference is that in IPv4 you have the choice between manual 
configuration and DHCP, so absense of the former implies that the 
latter must be used. There is no such dichotomy in IPv6: absense of 
manual address configuration doesn't mean DHCPv6 should be used. IPv6 
hosts have enjoyed the benefits of stateless address configuration for 
years and it's very likely that huge numbers of people running IPv6 
networks will never want to run DHCPv6. So requiring hosts to always 
try DHCPv6 doesn't make any sense.

---

From: Alain Durand <[email-masked]>
Date: Mon, 26 Apr 2004 13:53:37 -0700

On Apr 26, 2004, at 1:10 PM, Iljitsch van Beijnum wrote:

> So you object to the security level of DHCPv6 rather than that of the 
> M and O bits?

You should read what I just said above before commenting too quickly.
I have nothing against DHCPv6, but against insecure commands that
trigger a configuration mechanism, any configuration mechanisms.

> protection against a rogue DHCPv6 server over the situation you 

Again you commented without reading what I wrote.
People who run DHCPv4 on the client side decide to do so,
it is not that DHCPv4 client is triggered by a remote mechanism.

I never said that if you implement DHCPv6 you MUST always turn it on.
This is a decision that has to be made by the person configuring the 
host.

> would the M and O bits be in the way in that case? Just ignore them.

Because the specs says I should (lower case) obey M & O. Read what I 
wrote.

> Maybe because the IETF has no business to tell people in which way 
> they should run their network, but only to provide them guidance on 
> how a certain task can be performed in an interoperable way IF and 
> WHEN the operator decides they want this task to be performed in the 
> first place.

This is a general statement that nobody can disagree with but has no 
relevance to the discussion.
Sorry.

> Don't you consider this useful?

Ah, this is a very good question, actually, at the core of the 
discussion.
Thank you for asking it.

I'm not sure this is useful. You seem to think it is. Please tell me 
which problem it solves.

> as easily perform the same thing using just RAs.

Not only that. A host might have been previously configured with the 
address of a DNS server. There is a risk
that the O bit will trigger a query to find out the DNS server, and a 
corrupt entry will either override or complement
the correct one. This way the attacker could redirect part or all of my 
web traffic wherever he wants without having
to mess with the routers. Of course DNSsec will help, but it is not 
there yet.

> try DHCPv6 doesn't make any sense.

You obviously did not talk to the same IT folks in large enterprises I 
do.
Many do not like stateless autoconf much and would like to run DHCPv6 
for address allocation.
There are a number of very good reasons for that, especially for 
servers.

And again, "requiring hosts to always try DHCPv6" is not what I want.
I'm saying, if a host wants to try DHCPv6 for its configuration, that 
is fine, but this
is a configuration decision, and there are many situations where it is 
not wise
to have DHCPv6 triggered automatically by insecure messages on the 
network.

	- Alain,

---

From: "S. Daniel Park" <[email-masked]>
Date: Tue, 27 Apr 2004 14:02:58 +0900

> > Don't you consider this useful?

I have no hard stance whether to remove M&O bits
or not at this stage, however if we remove it, I 
guess somebody will sporadically define similar 
flags into the RA repeatly so as to perform that 
kind of operations. Of course it can be a separate 
document. Nevertheless, M&O bits (or newly 
defined flags outside RFC2462) is useful to trigger 
DHCP operation to the host and we need it.
e.g., recursive DNS server configuration.

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

---

From: Alain Durand <[email-masked]>
Date: Mon, 26 Apr 2004 22:29:20 -0700

> e.g., recursive DNS server configuration.

I think you are making a good case for moving O&M out of 2462bis
into a separate experimental RFC.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Tue, 27 Apr 2004 10:21:02 +0100

On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote:
> ...

Alain,

Could you explain how the functionality of the O/M bits will be replaced
within the ND/etc protocols?  Or should they not be replaced?

Until now, most people have not worried about DNS resolver discovery because
they run dual-stack networks (and thus use IPv4 transport DNS), but hosts
autoconfiguring in an IPv6-only environment need a method to get DNS and 
other configuration info.  I agree they can just try DHCPv6, rather than
being told to do so.  So is your argument that the client should decide which 
protocols to try, as per IPv4, rather than be "forced" to use DHCPv6 when 
DHCPv6 may not be secure?  

But whether the client decides to use DHCP, or an RA tells it to do so, there 
is no way to know whether the DHCP response is from a real or malicious server
(who uses authenticated DHCP? :).   And if you're not using DHCP you trust 
the RA for the network settings anyway.   So isn't SEND the answer to this, 
rather than deprecating flags?   You either run in an authenticated/trusted 
environment, or you don't...

At present I would agree with the WG chairs' view.

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 Apr 2004 11:39:50 +0200

> You should read what I just said above before commenting too quickly.

"It is not that DHCPv6 cannot be made secure" doesn't sound like a 
whole-hearted recommendation to me.

> trigger a configuration mechanism, any configuration mechanisms.

Ok.

> Again you commented without reading what I wrote.

I don't think so.

> it is not that DHCPv4 client is triggered by a remote mechanism.

As I explained in my message, even though DHCPv4 and DHCPv6 in 
themselves are pretty much the same thing, their place in the order of 
things is very different because IPv6 also has stateless address 
configuration and IPv4 doesn't.

> This is a decision that has to be made by the person configuring the 

I agree in principle. I'm afraid that if DHCPv6 becomes widespread it 
will be turned on out of the box, though. So we should be prepared for 
that.

> Because the specs says I should (lower case) obey M & O. Read what I 

So then we make the spec not say that.

> relevance to the discussion.

It has a lot of relevance. Obviously, when someone wants their hosts to 
be configured through RAs or through DHCP, then the implementation 
should follow the respective rules of the protocol in question. But 
which protocol (if any) someone wants to use to configure their hosts 
isn't something that should be standardized. This goes directly to your 
objection that when the M/O bits are set you should (lower case) do 
DHCP.

> I'm not sure this is useful. You seem to think it is. Please tell me 

Ever since I got myself an IPv6-capable laptop I hardly leave the house 
without it.  :-)

Now at present, it doesn't support DHCPv6. But suppose in the next 
version of my favorite OS DHCPv6 is supported, and I decide I want to 
run it. So far so good. But if I now take my laptop to a place where 
there is no DHCPv6 server, I either have to reconfigure my network 
settings (always a drag) or I have to wait for DHCP to time out.

It gets more complex when I really want hosts to use DHCP exclusively 
and not use stateless address configuration. Simple solution would be 
to turn off RAs, but then hosts that don't support DHCPv6 don't work 
anymore (and I don't have anything to fall back on when the DHCP 
server(s) are down). So in these cases I want RAs to be present, but 
have them be ignored by hosts that support DHCP.

This can all be accommodated by changing the meaning of the M and O 
bits slightly (in a backward compatible manner) as I outlined in a 
message a few days ago.

And even if we don't want to do this here and now, it's more useful to 
leave the bits in place and revisit the issue later in another document 
rather than remove or deprecate them.

>> So what kind of bad stuff is going to happen when hosts start 
>> querying a rogue DHCPv6 server? I think the main problem is that 
>> traffic can be redirected through a rogue router which then has the 
>> opportunity to perform man in the middle attacks. However, the rogue 
>> system can just as easily perform the same thing using just RAs.

> address of a DNS server. There is a risk that the O bit will trigger a 
> query to find out the DNS server, and a corrupt entry will either 
> override or complement
> the correct one. This way the attacker could redirect part or all of 
> my web traffic wherever he wants without having to mess with the 
> routers. Of course DNSsec will help, but it is not there yet.

Ok.

However, wouldn't this be an issue that is best addressed in DHCP? I 
can imagine DHCP info being protected using a certificate, and clients 
only accepting DHCP information from servers that they have a 
certificate for.

>> IPv6 hosts have enjoyed the benefits of stateless address 
>> configuration for years and it's very likely that huge numbers of 
>> people running IPv6 networks will never want to run DHCPv6. So 
>> requiring hosts to always try DHCPv6 doesn't make any sense.

> You obviously did not talk to the same IT folks in large enterprises I 

Probably not, and certainly not about DHCPv6.

I'm not saying DHCPv6 is useless and nobody wants it. What I'm saying 
is that it's perfectly possible to run an IPv6 network without DHCPv6 
and many people will continue to do so. Whether this will be 10/90, 
25/75, 50/50, 75/25 or 90/10 % doesn't matter much in the long run as 
even 10% of the networks running IPv6 is going to be a huge number in 
the long run.

> for address allocation. There are a number of very good reasons for 
> that, especially for servers.

Sure. There are also good reasons to not want to run DHCPv6, so we'll 
see people do both. (Quite possibly within a single network, too.)

> is fine, but this is a configuration decision, and there are many 
> situations where it is not wise to have DHCPv6 triggered automatically 
> by insecure messages on the network.

I agree. However, there are situations when security isn't the first 
consideration (it's always _a_ consideration of course) and then having 
the bits as hints to avoid engaging in a protocol that will only time 
out will be very useful. Also, RAs are insecure today but that doesn't 
have to be so in the future.

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Tue, 27 Apr 2004 13:16:07 +0200

I fully agree with the chair's decision to leave the M/O bits unchanged
for now.

I would like to quickly address (comments inline) the security argument
that was raised by Alain.

Alain,

> an automatic and insecure way to trigger an external configuration 
Well, but so is the whole method of sending RAs. Frankly, malicious
DHCPv6 servers or RA "emitters" are easy to detect and I don't see any
change in the threat level no matter if the M/O bits are there or not.
An administrator needs to keep an eye on each broadcast domain where RAs
are sent and where DHCPv6 is deployed anyhow to make sure that no
malicious information is sent by rogue machines. If that is done,
sending configuration hints to clients is a very useful feature in my
eyes.

> Host should not blindly believe this unless the RA are secured.
That is true. But until this is achieved by some kind of additional
mechanism, I don't see why having the M/O bits adds to the danger.
Securing RAs is another issue.

One final comment I would like to add to the implementation discussion
(in parallel threads) is that NEC's DHCPv6 reference implementation also
included support for M/O bits. And since this implementation was used
for major DHCPv6 plug tests (e.g. by ETSI, etc.), we shouldn't neglect
it.

Christian

---

From: Alain Durand <[email-masked]>
Date: Tue, 27 Apr 2004 09:21:54 -0700

> settings (always a drag) or I have to wait for DHCP to time out.

I see your point, but I think a smart implementation will not have to 
wait for DHCPv6 timeout.
You could start working with stateless autoconf, that will get you 
started, and if DHCPv6 kicks in,
you will simply reconfigure dynamically. Not really different than 
receiving a second RA
1 or 2 seconds after the first one...

	- Alain.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 28 Apr 2004 19:28:39 +0900

Note: I'm responding to an old message not to restart the
"deprecation" discussion, but to make progress on how we can clarify
the things about these flags, assuming we have agreed on keeping them.

My point in this message is that IMO we should specify the protocols
corresponding to these flags clearly and concretely, without leaving
any ambiguity (I've changed the subject accordingly.)  That is, I
strongly believe we should clearly say in rfc2462bis, *for example*,

- the protocol that should be invoked by the M flag is DHCPv6
  (RFC3315), and nothing else
- the protocol that should be invoked by the O flag is stateless
  DHCPv6 (RFC3736), and nothing else

>>>>> On Sat, 24 Apr 2004 11:23:39 +0200, 

> lead to real-world problems.

What we have seen is some confusion among implementors.  What I expect
if we continue to keep the specification unclear is real-world
problems.  One important difference is that now we have (at least)
RFC3315 and RFC3736 standardized as RFCs, and it will be more likely
for implementors to implement these protocols based on their
interpretation of the O/M flags, increasing the risk of making the
confusion real-world problems.

(Not sure if this is the elaboration you wanted, but I don't see
anything unclear in what I said in the quoted part above.)

> compatible so the change doesn't make any difference to code that is 

This is exactly why I want to be very clear on the protocols invoked
by these flags.  For example, if we leave it ambiguous what is the
protocol that should be invoked by the O flag, we'll see many kinds of
host implementations regarding the protocol; one may invoke the full
DHCPv6 (RFC3315) client.  Another one may invoke stateless DHCPv6
(RFC3736) client.  We may see yet another one that invokes SLP client.
Then we'll have hosts according to 2462bis-RFC3315, 2462bis-RFC3736,
2462bis-SLP, 2462bis-xxx, ...

One thing I'm worried about in the past discussion is that there seems
to be an opinion that the implementation/deployment status for
RFC3315/RFC3736 is too immature to be clearly specified for the M/O
flags (but in a different context, disagreeing the idea of deprecating
the flags).  If this type of opinion also indicates that we should
rather keep the corresponding protocols ambiguous, I strongly
disagree.  In fact, I'd rather "deprecate" these flags, whatever it
means, than to keep them ambiguous (I hope we won't have to fight this
discussion again).

(Meanwhile, I would have answered in the previous thread that this
should be almost non issue in a practical sense while this is surely
an issue theoretically.  Since there are almost no host
implementations for the M/O flags, we'd still have actually old+new
implementations regardless of whether we deprecate the flags or not.
Similarly, setting these flags on RFC2462 routers has no effect in a
practical sense, so we'd still have old+new implementations regardless
of whether we deprecate the flags or not.  But I'm not intending to
fight for this discussion, so you don't have to be bothered to make a
counter argument on this part.)

> Now lets focus our attention on what we want to accomplish 

(snip)

>		 before initiating communication that requires other 
>		configuration.

I don't have a strong opinion on whether we should specify in
rfc2462bis this level of details for all the combinations of the
flags; at the moment my take is not to describe this.  But if others
also want to include the specification and if we can quickly agree on
a particular behavior, I don't mind to contain the result.

In any event, I have a concern with the phrase of "RA other
configuration".  First, it's not clear what the phrase means.  I guess
you intended something like so called "DNS (recursive) server option
in RA", but such a thing is quite controversial; there is even a
discussion on whether we need this type of information in RA in the
first place.  So, considering the "conservative" aspect of rfc2462bis
work, I don't think rfc2462bis can contain this type of immature
notion.  (I don't necessarily oppose to discussion about such a notion
in a separate document as an extension or further clarifiation to
2462/2462bis.)

And finally...

(the following is not a comment from a technical point view, but I'm
going to make it because I think it will be helpful to make further
discussion productive.  But in any event I'll refrain from making
further posts on this particular topic since it's surely off-topic.)

> operational feedback. This is especially apparent with regard to the 

You have complained about this kind of general topics in the
"deprecation" thread.  I'm not sure about your real intention because
it was too generic.

If you've been just complaining about (recent?) decision process in
the IETF, I sort of have sympathy with you.  But it's irrelevant to
this particular discussion (at least it does not have a direct
relationship), so please do that somewhere else (you may want to go to
open mike sessions in IETF meetings :-)

On the other hand, if you have tried to claim that the proposal in the
previous thread just came from theoretical considerations without
venturing the real world and/or asking operators (and thus that the
proposal was bad), I'd refute the argument by the following two
points:

  - first, I believe I made the proposal based on my experiences of
    "venturing the real world and asking operators", rather than
    "theoretical considerations" (see below).  If something that I
    proposed was not so convincing for you, it would probably because I
    failed to convey my experience very well, not because I made it
    based on "theoretical considerations".

    BTW: How can you be sure that a person that you are not very
    familiar with is making an argument just from theoretical
    considerations?  Different people have different backgrounds of
    "venturing the real world", and it's hard for a third party person
    to prove that an argument based on a different background really
    comes from "theoretical considerations".  With all due respect,
    you seem to have been insisting that opinions based on a different
    operational background than yours are just based on "theoretical
    considerations."

  - secondly, and more importantly, even if you can prove that someone
    is making an argument just from "theoretical considerations", does
    it help anything to complain about the fact?  I must admit I might
    be not very convincing in some (or most?) cases, but then you can
    just point out the flaw of the argument, rather than complaining
    about what the argument comes from.  At least I'm always willing
    to be corrected when I'm wrong, whether the counter argument is
    based on "real world experience" or on "theoretical
    considerations", as long as it is reasonable.

You've actually made very good technical points, which I think are
necesary and sufficient to have productive discussions.  It would
really be helpful to concentrate on the technical points, without
complaining about what arguments come from.  It is in general
difficult to prove the background of an argument, and even if you can
do that, I don't think it helps anything.

As an appendix, I'm going to argue that I've made my proposals based
on my own experience of "venturing the real world and asking
operators" by describing who I believe I am.  If you still think I've
been acting just based on "theoretical considerations", please feel
free to defeat me by proving that, either in a unicast response or a
response on the list (though I won't make further responses in
public).

I operate my own IPv6 networks.  I operate IPv6 routers from various
vendors, I've configured and do manage an IPv6 firewall, and I've set
up and do operate IPv6 web/ftp/DNS/mail servers.

I'm struggling with the migration from ip6.int to ip6.arpa, and I
admit it's weird.  (For that matter, I was not there when the decision
was made.)

I've also developed, and I'm still developing, IPv6 related products.
I've implemented neighbor discovery and stateless address
autoconfiguration (with my co-workers), I've implemented stateless and
stateful DHCPv6 servers/clients/relay agents.

I'm using IPv6 every day.  I read or send email over IPv6, log in to
remote hosts by ssh over IPv6, browse web pages over IPv6 when
reachable via IPv6, and so on.

I've configured several routers in my networks so that they set the O
flag in router advertisements, and have seen how it could interact
with my stateless DHCPv6 client.  When and where available, I
configure the recursive resolver's address on my laptop through the
stateless DHCPv6 client.  I've seen several problems during my
experience, on which I've presented my opinion/proposal here.

I have several friends and co-works who work for ISPs operating their
IPv6 networks.  I often have a chance to discuss operational issues of
IPv6 they face with them, and I at least have tried to reflect the
results of such discussions in technical discussion in the IETF.

					JINMEI, Tatuya

---

From: Tim Chown <[email-masked]>
Date: Wed, 28 Apr 2004 13:28:11 +0100

>   DHCPv6 (RFC3736), and nothing else

But in reality nodes will have full DHCPv6 client support in them (3315)
whether or not they then see the M or O flag that is what they will use?

All the DHCPv6 servers implemented to date, to my knowledge, are 3315 and
not the 3736 subset.   

So it is better to just say O flag is other (non address) configuration
data, regardless of full/subset of DHCPv6 used?

Tim

---

From: Markku Savela <[email-masked]>
Date: Wed, 28 Apr 2004 15:46:02 +0300

I believe DHCP for IPv6 is totally incorrect direction. It's a
leftover dinosaur from IPv4 way of thinking.

The whole DHCP6 concept should not have been designed. Instead, the
effort should have gone to extend the standard IPv6 configuration
framework: neighbor discovery.

If configuration is needed, add new messages to the ND ICMP's, or
options to the router advertisement.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Apr 2004 11:17:05 -0400

Well, picking up the thrown gauntlet - can't resist just this once - if the
IETF hadn't spent so much time deciding how many spokes to put on all the
wheels being reinvented, we'd have a complete and fully operational set of
specs for a deployable IPv6 service by now.

- Ralph

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 29 Apr 2004 00:29:41 +0900

>>>>> On Wed, 28 Apr 2004 13:28:11 +0100, 
>>>>> Tim Chown <[email-masked]> said:

> data, regardless of full/subset of DHCPv6 used?

Aghhh....you have jumped to the next stage.  I didn't intend to
propose any particular protocols for the M/O flags in the above
message.  I first wanted to make it clear that we should clearly
specify particular protocols for the M/O flags, whatever they are.
That's why I emphasized the phrase "for example" by the set of
asterisks.

(In fact, I planned to add another note e.g., "even if we can agree on
this approach, which protocol should be used for each flag is a
separate question".  I thought this was clear by the emphasized "for
example", but apparently I was naive...)

Since discussions in this thread has tend to diverge, please make it
step-by-step.

					JINMEI, Tatuya

p.s. since you've already made a further step anyway, I'd clarify one

> All the DHCPv6 servers implemented to date, to my knowledge, are 3315 and

This is not correct.  The DHCPv6 server provided by the KAME project
conforms to RFC3736, but does not fully conform to RFC3315.  More
importantly, there should be few implementations that conform to
RFC3315 including the ability of configuring IPv6 addresses by DHCPv6.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 29 Apr 2004 01:04:16 +0900

>>>>> On Wed, 28 Apr 2004 15:46:02 +0300, 
>>>>> Markku Savela <[email-masked]> said:

> options to the router advertisement.

Well, I don't understand in which context you're making the above
points because you even did not refer to any part in this thread...

If you are trying to propose a particular action for the M/O flags in
rfc2462bis, please clearly make your proposal.  Otherwise, (and
especially if it is not related to any part of rfc2462bis) please
make a separate thread to discuss your opinion.

Thanks,

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Wed, 28 Apr 2004 12:16:15 -0400

I think the O flag (if we keep it!) should simply specify DHCPv6, with no
implication about the way in which DHCPv6 is used.

"Stateless DHCPv6" is simply a way to use some of the messages from the full
specification in RFC 3315.  RFC 3376 is a guideline to the implementation of
DHCPv6 that uses just Information-request/Reply messages.  A client can
choose to use the Request/Reply or the Information-request/Reply message
exchange to obtain other configuration information without address assignment.

- Ralph

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 28 Apr 2004 18:35:06 +0200

On 28-apr-04, at 12:28, JINMEI Tatuya / 神明達哉 wrote:

> For example, if we leave it ambiguous what is the
> (RFC3736) client.

(My apologies for having to ask, but life is short and wgs are 
aplenty...) What is the difference between stateful and stateless 
DHCPv6 anyway, as seen from the client? It seems a bit strange to me 
that the client should care about the internals of the server.

> We may see yet another one that invokes SLP client.

Yes. I appreciate that life would be much simpler without having all 
these different options to support. But don't you think that people 
running networks may have very good reasons to prefer one protocol over 
another? So unless one protocol is so great that it suits everyone's 
needs, this will happen whether we put it in an RFC or not. I think it 
makes sense to face this reality now but I don't see how what we do in 
this reggard makes life for people running networks much harder so I 
don't feel too strongly about it.

> a particular behavior, I don't mind to contain the result.

The question is: what kind of bad stuff happens when people implement 
different ways to do this? If the answer is: lots of stuff, then we 
probably need something like this in the document. If the answer is: 
nothing much, then there is little need to bother.

> configuration".  First, it's not clear what the phrase means.

That's a feature, not a bug.  :-)  There is always a tradeoff between 
being specific and being general.

In theory, RAs can contain all kinds of interesting information, 
although in practice this info is fairly limited to stuff like the link 
MTU.

> I guess
> in RA", but such a thing is quite controversial;

That's why it's better to look at the general mechanism rather than any 
specific type of use of the mechanism. RA is mentioned along with 
static configuration, which is of course completely non-controversial 
as a source for recursive DNS server addresses.

> there is even a
> notion.

If you are 100% sure that there will not be any information that can be 
both in DHCPv6 and in RAs I agree.

> further posts on this particular topic since it's surely off-topic.)

Hm...

> "deprecation" thread.  I'm not sure about your real intention because

Since you bring it up... I'm highly frustrated by the fact that if I 
bring my laptop to a place with IPv6 connectivity, I can't just connect 
to the network and enjoy the benefits of said IPv6 connectivity because 
there is no way to automatically configure DNS resolvers. And even 
worse than the fact that after nearly a decade such a simple yet 
important thing hasn't been solved is the fact that there is a 
significant number of people actually blocking this for various reasons 
that obviously make sense to them but not to me. Although this is the 
most egregious example, it's not the only one. I already mentioned 
ip6.int/ip6.arpa, then there is the fact that it took 8 years to figure 
out that site locals are a non-starter, the RIR/IANA publish an IPv6 
address policy and then don't stick to that policy. That kind of thing.

Now I appreciate the fact that going out in the world with a certain 
view of how things work and then expecting everyone and everything to 
conform to this view is the quick road towards disappointment, but I 
think all of this goes beyond that. IPv6 is a huge project and 
obviously mistakes will be made in such projects. But if the question 
how all of this plays out in the real world isn't given much attention, 
if any, there are deeper issues.

> open mike sessions in IETF meetings :-)

I promise I'll be at the next one that's in a country where you don't 
have to submit to finger printing like a common criminal to get in.

>     "theoretical considerations" (see below).

Ok.

Note by the way that theoretical considerations are not bad, they are 
hugely important. But while in theory there is no difference between 
theory and practice, in practice there is. We need both.

>     operational background than yours are just based on "theoretical

You are right, I spoke too harshly. All of this is in the eye of the 
beholder: what happens here _seems_ mostly theoretical with little 
operational considerations to me, but I'm not qualified to determine 
whether this is actually so.

> complaining about what arguments come from.

I agree and that's why you see much more technical points than general 
complaints from me.

> up and do operate IPv6 web/ftp/DNS/mail servers.

Ok, going to be very careful now, as I certainly don't want to repeat 
my earlier mistake. But... (there is always a but.)

I am somewhat familiar with the (IPv4) interdomain routing world. When 
I compare the issues that are relevant in IPv4 idr with what happens in 
IPv6 idr, it's hard to avoid the impression that lots of stuff that 
happens in IPv6 is fairly amateurish. Obviously there are many people 
who are very skilled and know exactly what they're doing in IPv6, but 
there is also a considerable group that's mostly playing around without 
much clue of real-world issues. For instance, there is a significant 
issue in IPv6 that "everyone gives everyone transit": many networks are 
so impressed by the fact that they're running IPv6 that they provide 
transit service to every other network they're connected to, often over 
tunnels and sometimes without even telling the other party that they're 
doing this. With the result that a while ago IPv6 connectivity was much 
hampered by the fact that the real network topology was hidden from BGP 
so lots of traffic want over tunnels where it didn't need to. 
Fortunately this is getting much better relatively fast now. Another 
issue is that since there are few real-world concerns ("do XXX or 
you'll lose my business") in IPv6 so a significant number of networks 
has policies that represent how the administrator of that network views 
the world rather than what makes sense in running a commercial network.

So I guess what I'm saying is "where is Randy Bush when you need him".  
(-:

---

From: Alain Durand <[email-masked]>
Date: Wed, 28 Apr 2004 11:37:12 -0700

> within the ND/etc protocols?  Or should they not be replaced?

I'm not convinced they are needed in the first place.

> DHCPv6 may not be secure?

It has nothing to do with DHCPv6 being secure or not.
I think it is up to the client to decide what to do. I have nothing 
against
hints provided by the network that DHCPv6 may be here, but I'm not
comfortable in having host being told to use it despite other 
configuration
they may have.

> the RA for the network settings anyway.

not necessarily. You can use manual config. Or still use stateless 
autoconf
and have an external verification.

>  So isn't SEND the answer to this,

I agree with you for the M bit. Not for the O bit, as you can trivially 
mount attacks
that were more difficult to do before. Overriding the configuration of 
the DNS server
would be much more difficult to detect than overriding the default 
router.

	- Alain.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 29 Apr 2004 14:50:26 +0900

>>>>> On Thu, 29 Apr 2004 00:29:41 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

(snip)

> That's why I emphasized the phrase "for example" by the set of

Hmm, despite the notice, people have started and explored the
specific discussion on which protocols should be specified for the M/O
flags and how we describe it...

Please recall such a discussion will become meaningless (in the scope
of rfc2462bis) unless we can agree on specifying particular protocols
for these flags.  So let's first make a consensus on this.

I guess it's okay for most of those who joined the specific discussion
to specify particular protocols.  In fact, they seem to have assumed
the agreement.

Can we think this shows a consensus here?  If someone strongly
disagrees with this idea, please speak up right now.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 29 Apr 2004 22:46:19 +0900

>>>>> On Wed, 28 Apr 2004 12:16:15 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> exchange to obtain other configuration information without address assignment.

A quick question for clarification: do you mean a client can choose to
use the request/reply message exchange to obtain other configuration
information without address assignment (in addition to
information-request/reply exchange)?  If so, I have several related
questions.

In this scenario, the client first sends a Solicit message.

RFC3315 says in 17.1.1 that

   The client includes IA options for any IAs to which
   it wants the server to assign addresses.

If the client does not want address assignment, is it okay for the
client to send a Solicit without including an IA option?  It's not
clear to me, but this is probably okay (at least the RFC does not seem
to prohibit it).

Then, the server seems to take the following action according to
Section 17.2.2 of RFC3315:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.

And the client will ignore the Advertise message because in Section
17.1.3 the RFC says:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

and so the exchange should fail at this stage.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 29 Apr 2004 23:00:00 +0900

>>>>> On Thu, 29 Apr 2004 14:50:26 +0900, 

> disagrees with this idea, please speak up right now.

It might be too early to conclude, but I interpret the silence as an
agreement at the moment.

So, what we've agreed on so far are:

- we'll keep the M and O flags
- we should clearly specify the protocols corresponding to the flags
  (without leaving ambiguity)
- the protocol for the M flag is DHCPv6 (we've already reached a
  consensus on this, but I mention it explicitly because we've had
  some fundamental discussions)

And what we should discuss from now on are:

- which protocol should be used for the O flag
- details of the relationship between each flag and protocol, e.g.
  whether we should mandate to invoke the protocol or we can just
  regard the flag as a hint and let the host decide if it invokes the
  protocol (as Christian suggested), etc.

I'll be off from the list for a vacation until May 7th.  Hopefully the
discussion will continue in a productive manner during the period but
will not diverge very much:-)

Thanks,

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 18:12:02 +0300 (EEST)

>   protocol (as Christian suggested), etc.

I support Christian's suggestion; they should be just hints.  

No flag is going to force the node to run a protocol.  More often than
not, for implementation simplicity, I'd guess most nodes (especially
where DHCPv6 is available), the nodes are going to run DHCPv6(-lite)  
in any case, whether they saw a flag or not.

On the other hand, absence of a flag is not going to prevent a node
from running a protocol.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Thu, 29 Apr 2004 18:14:38 +0200

> client to send a Solicit without including an IA option?  It's not
That should be possible, yes. The purpose of a solicit message is to
find a DHCPv6 server or a relay agent, there's no implication that it
has some immediate connection to address assignment (which makes IA
options mandatory).

> and so the exchange should fail at this stage.
That is only true if the client included an IA option in a request in
the first place (e.g. to ask for an address for this particular
interface that is in this IA). If it did not include any IA options, the
server consequently does not have to set the status code of the
advertise message to NoaddrsAvail because address assignment can only be
done in the context of an Identity Association.

Cheers,
Christian

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Thu, 29 Apr 2004 18:58:57 +0200

> I support Christian's suggestion; they should be just hints.  
I also support this suggestion.

> in any case, whether they saw a flag or not.
Your first statement is correct, but I think that it is important to
stress that the M/O bits should not be seen as trivial or unimportant
because they have no mandatory implications. Even if they're "only"
hints, they're quite useful in some scenarios.

Next to the protocol authority, there's the administrative authority.
It's not the node that choses whether or not it's going to run a
protocol in this particular case. It's the administrator who puts a
DHCPv6 client onto the machine that respects the M/O bits or not and who
decides if he wants to set certain M/O bit combinations in his site for
one reason or the other (think WiFi spots with SAA and stateless DHCPv6,
think cluster nodes without any SAA and with stateful DHCPv6 for full
control and think about machines that need to detect whether or not they
need to use SAA or stateful methods depending on their location
(portable nodes)). So, you get a consistent behaviour since it's the
administrator who decides about the usefulness of utilising the M/O bits
(client side and "RA emitter" side).

Christian

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Thu, 29 Apr 2004 19:24:56 +0200

> and so the exchange should fail at this stage.
I just realised some implications of your post. As I wrote in my other
mail, the client indeed does not need to send IA options and hence the
NoAddrsAvail will not be sent to the client in an Advertise message, if
no IA options are used in the first place. 

But the real question is: does the client actually know when it doesn't
need to send IA options? Consider this scenario:

- O bit is set in RAs
- DHCPv6 server is configured _not_ to assign addresses to DHCPv6 
  clients (SAA is used)
- there is a DHCPv6 client that DOES NOT respect the O bit and
  consequently will request an address from the DHCPv6 server next
  to information options (DNS, etc.)

In this case, the client doesn't know that it doesn't actually need to
request an address and it will use IA options consequently. Hence the
retrieval of information options will fail for the reasons you
identified. That is, needless to say, bad. The only way around it is to
either beforehand configure the client not to be a stateful DHCPv6
client or to only use a DHCPv6 client that respects the O bit. On the
other hand, if you by default configured stateless DHCPv6 you would be
lost in a subnet without RAs. So, the only way out of this dilemma is to
have a DHCPv6 client that respects the M/O bits.

Christian

---

From: Tim Chown <[email-masked]>
Date: Thu, 29 Apr 2004 18:29:57 +0100

> I support Christian's suggestion; they should be just hints.  

It says "should" in 2462, not MUST?  You want "may"?   So it's not mandated
at the moment, unless there's reference in another RFC?

Tim

---

From: Alain Durand <[email-masked]>
Date: Thu, 29 Apr 2004 15:57:50 -0700

On Apr 29, 2004, at 10:29 AM, Tim Chown wrote:

> It says "should" in 2462, not MUST?  You want "may"?

Essentially, yes, I'd like to see a "MAY" instead of a "should".

	- Alain.