Subject: RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

From: [email-masked]
Date: Thu, 6 Feb 2003 15:31:44 +0200

Hi all!

I support the proposal below & the idea having DHCPv6 support as a MAY.

Best Regards,
		-Juha W.-

-----Original Message-----
From: ext Jari Arkko [mailto:[email-masked]]
Sent: 06 February, 2003 15:15
 
> In general, stateless address autoconfig is a good thing, so we want
> to encourage service providers to do the right thing.

Maybe the right thing is to attach a warning or an explanation
about the implications and leave the support as a MAY. For
instance,

   "Nodes that do not implement DHCP may become unable to
    communicate outside the link when their routers advertise
    stateful autoconfiguration and no prefixes suitable
    for stateless autoconfiguration are offered."

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Bound, Jim" <[email-masked]>
Date: Wed, 12 Feb 2003 00:03:08 -0500

John,

It should be SHOULD.  The M bit means "use" Tasteful.  The "O" bit means
use Stateful.  Two different contexts.  I was here when they were put in
ND and recall why.  One reason is that not everyone believed that just
stateless was acceptable and that was vision on those persons part.  The
reality is that most users will not use stateless but Statefull simply
out of habit first of all and second the trust model will not be
delegated to routers for IPv6 for some time until users are more
comfortable with the stateless model.  I also consider not doing a
SHOULD for these bits is irresponsible engineering of a standard on our
part.  If a user wants stateful which is clearly permitted in ND and in
the IPv6 architecture they should be able to use it. But reality is that
as any product engineer knows when you develop the code first time and
see MAYs you usually skip it. But that is just a side issue and logic.
The reason is as I said.  M/O bit says use stateful. For this to not be
a SHOULD is to denigrate a part of the IPv6 architecture and this is
simply wrong.

Putting words in that if you do this you will hurt yourself tells us it
should be a SHOULD.  If something can hurt users and this can it can
affect interoperability and deployment.  I could also argue if the "M"
bit is set and nodes don't go to a stateful server because they "cannot"
it is another form of DOS.

The case where I personally don't believe stateful is valid is for small
mobile devices for users like 3GPP, 802.11 hot-spots, military
operations, et al.  But in those cases.  Except in one scenario which I
won't get into.  Long term I see stateless used  more and more, but I
don't see Enterprises or any very large entity using stateless for a
very long time. But in cases where it might not make sense the market
will decide and not set the M bit.  But if they set it then that means
it's a SHOULD.

SHOULD means implement this unless you have a good reason to not
implement it.  For devices I spoke of above there is good reason to not
implement it IMO so don't.  

Small device only believers and die-hard stateless is the only model
should not use this forum to backdoor remove what is part of the IPv6
architecture.  I believe if we do that then it must be raised to a
higher level and question of Internet Architecture principles based on
the base specs for the architecture.

The other problem is that stateless brings with it many problems we will
have to deal with in deployment till we learn more. The users will see
this too and will be conservative and drop back to stateful.

This is a very serious issue.

Regards,
/jim

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 12 Feb 2003 12:09:16 -0800

> stateless was acceptable and that was vision on those persons part.

We had a conclusive discussion off this point during the interim WG
meeting in Sunnyvale. The reasoning goes as follow: if we want to
maximize interoperability, we want to have a single mandatory address
configuration procedure, not two; everybody agrees that we must support
stateless address configuration; thus we should make stateless
mandatory, and other configuration methods optional.

This is properly reflected in section 5.3 (nodes MAY support DHCPv6), in
section 4.5.2 (MUST support stateless) and in the current text of
section 4.5.5, which is just fine.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Feb 2003 16:21:57 -0800

I agree with this and think that a MUST for stateless and MAY for DHCP is 
fine.

Bob (with no hats on)

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 13 Feb 2003 01:10:32 -0500

> > use Stateful.  Two different contexts.  I was here when 
> they were put
> in
> We had a conclusive discussion off this point during the 
> interim WG meeting in Sunnyvale. The reasoning goes as 
> follow: if we want to maximize interoperability, we want to 
> have a single mandatory address configuration procedure, not 
> two; everybody agrees that we must support stateless address 
> configuration; thus we should make stateless mandatory, and 
> other configuration methods optional.

I was at the meeting.  I did not hear consensus for this at all or in
mail follow up or at Atlanta.  I don't believe all agree with this view
at all and I know all the users don't and all the vendors don't and all
on this list.  So what do you mean by all?

> 
> This is properly reflected in section 5.3 (nodes MAY support 
> DHCPv6), in section 4.5.2 (MUST support stateless) and in the 
> current text of section 4.5.5, which is just fine.

The reason I did not object to that is because DHCPv6 had not reached
proposed standard I will have to think if I object to that now that you
bring it up.  But DHCPv6 is just one method of Statefull we know today,
and probably should be a MAY but now will think on that too.  So the two
references are orthognal. 

Besides M there is O bit.  That means use statefull for other
configuration and that is another issue.

The implementation of M and O bit should be a SHOULD.  I do not believe
we have consensus on the view you state above.  Nor do I believe that
all discussion points have been brought forth for such an important
decision.  

Regards,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 08:28:11 -0500

Fred,

> I'm still of the opinion that some ambiguity exists. Namely, 
> if a prefix option has the Autonomous flag ("A" bit) set and 
> the on-link flag ("L" bit) NOT set, one could infer from 
> reading RFC 2462, section 5.5 that it is OK to go ahead and 
> configure an address from the (off-link) prefix as specified 
> in 5.5.3 d). But then, which link would one derive an 
> interface identifier from in order to form an address? (And, 
> which interface would one assign the address to?)

My read of this scenario as implementor is that I am to use offlink to
speak to my default router as one example but I cannot assume those
prefixes are on my link.  I believe within 2461 this is actually derived
but I have not scanned it but pretty sure.  Too much work for this
moment.

> 
> I believe this should be clarified somewere, e.g., in the 
> IPv6 node reqt's document. The challenge is in specifying 
> something that is neither too precise that it precludes 
> legitimate functionality nor too broad that it opens the door 
> to security holes and/or misconfigurations. In particular, if 
> it's not OK for a node to configure an address from an 
> advertised prefix with the "L" bit not set we should probably 
> say so somewhere and give some rationale.

This is stated. I will go look but it will be days before I come back.
But Thomas knows this spec probably from memory banks :--)