On 24-apr-04, at 7:46, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>> 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.
> 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.
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.
> 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?
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
> 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?
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.
>> 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.
> 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.
> 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.
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
> unclear specification and the misuse of the flags based on 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.
>> 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.
> If you're requiring to bring this discussion to the v6ops wg and ask
> them what they think, that's fine.
No, I don't think that will make a difference.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
- [rfc2462bis] whether we need the M/O flags JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis] whether we need the M... Ralph Droms
- Re: [rfc2462bis] whether we need the M... Alain Durand
- Re: [rfc2462bis] whether we need t... Alain Durand
- Re: [rfc2462bis] whether we need the M... JINMEI Tatuya / 神明達哉
- Re: [rfc2462bis] whether we need t... Alain Durand
- RE: [rfc2462bis] whether we ne... Russell Brian
- Re: [rfc2462bis] whether w... Alain Durand
- Re: [rfc2462bis] whether we need t... Iljitsch van Beijnum
- Re: [rfc2462bis] whether we ne... JINMEI Tatuya / 神明達哉
- the protocols for the M/O ... Iljitsch van Beijnum
- the protocols for the... JINMEI Tatuya / 神明達哉
- Re: the protocols... Tim Chown
- Re: the proto... JINMEI Tatuya / 神明達哉
- Re: the proto... JINMEI Tatuya / 神明達哉
- Re: the proto... JINMEI Tatuya / 神明達哉
- M/O flags: hi... Pekka Savola
- Re: M/O flags... Christian Strauf (JOIN)
- Re: M/O flags... Tim Chown
- Re: M/O flags... Alain Durand
- Re: the proto... Ralph Droms