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,
>>>>> Iljitsch van Beijnum <[EMAIL PROTECTED]> said:
>> 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.
> 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.
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.)
>> Secondly, if the situation is that immature, why can't we simply
>> deprecate the flags for now and leave the flexibility for future
>> 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.
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
> operationally.
(snip)
> 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.
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.)
>>> 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.
>> 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.
> 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.
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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
