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

[Iljitsch van Beijnum <iljitsch@xxxxxxxxx>]

On 24-apr-04, at 7:46, JINMEI Tatuya / $B?@L@C#:H(B 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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------