Re: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)

[Iljitsch van Beijnum]

On 28-apr-04, at 12:28, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:

> 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.

(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.
> Then we'll have hosts according to 2462bis-RFC3315, 2462bis-RFC3736,
> 2462bis-SLP, 2462bis-xxx, ...

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.

>> 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.

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.

> In any event, I have a concern with the phrase of "RA other
> 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
> you intended something like so called "DNS (recursive) server option
> 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
> 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.

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

> (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.)

Hm...

>> 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.

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.

> 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 :-)

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.

> 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).

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.

>     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."

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.

> 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.

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

> 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.

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".  
(-:


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