Subject: RE: draft-ietf-ipv6-node-requirements-03.txt

From: "Bound, Jim" <[email-masked]>
Date: Tue, 11 Mar 2003 09:59:08 -0500

It would save me from doing a legal like  brief (precedents in the IETF
for my case here) and major work to the IESG too :--)

But it really can work this way and appease all.

Except those who would like to see Stateful dead completely and I would
argue they should not win this debate because stateful is an equal
partner in the IPv6 architecture. I also question anyones motive that
believes stateful should be dead too.   

In addition the Enterprise wireline networks and IT are not going to
give up stateful control with servers and NAS in their networks for a
long time with IPv6 is my intelligence from my work with users.  

/jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, March 11, 2003 7:58 AM
> To: Bound, Jim; [email-masked]
> Cc: [email-masked]
> Subject: RE: draft-ietf-ipv6-node-requirements-03.txt
> 
> 
> Hi Jim,
> 
> I agree, I think it is a good compromise.
> 
> > I like Brian's suggestion folks.
> > /jim
> >
> > > "Bound, Jim" wrote:
> > > 
> > > much deleted...
> > > ...
> > > > My issue is about stateless and stateful being required features
> > > > within IPv6 for auto configuration.  Both are needed 
> and both are 
> > > > required.
> > > 
> > > I hope we all agree on this, using lower case. I think we
> > > have a genuine problem here in they way RFC 2119 defines 
> > > SHOULD - it makes it very strong indeed, maybe a bit too 
> > > strong for this case, whereas MAY is clearly too weak. Maybe 
> > > indeed we need to qualify the SHOULD, e.g. 
> > > 
> > > Stateful Address Autoconfiguration SHOULD be supported, unless all
> > > possible use cases for the specific implementation concerned 
> > > are clearly satisfied by Stateless Address Autoconfiguration.
> > > 
> > >    Brian
> 
> 

--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 09:06:35 +0200 (EET)

> long time with IPv6 is my intelligence from my work with users.  

Are servers and NAS configured with DHCPv4 today?

Not that I know of, we certainly don't do it (even though we use DHCPv4
for most workstations).  Of course, that's possible, e.g. by identifying
MAC-address in the servers etc., but I'm not sure if all that many folks
do it.

Don't underestimate the power of an admin doing manual 
configuration. :-)

So, my point is that there's a lot more to it than just "stateful" or
"stateless".

The critical point, IMO, is making the nodes able to easily configure
other parameters they'd like, using DHCP-lite, or other mechanisms like
that.  Few people prefer to punch all of that in manually.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Mar 2003 14:09:27 -0500

>Are servers and NAS configured with DHCPv4 today?

Yes.  The home NAT/router in my basement acts as a DHCP client
on the interface connected to the ISP and as a DHCP server on
the interface to my home network.

Your question does raise an interesting issue - where, in the IPv6
specifications, is the behavior of a router in response to received
router advertisements specified?  How does a router behave if
it receives an RA with either or both of the 'M' and 'O' bits
set?

Note that the DHCPv6 doesn't include the infamous sentence: "DHCP
is not intended for use in configuring routers."

I certainly anticipate routers using DHCPv6 for obtaining DNS
and similar configuration information, as well as prefix
delegation...

- Ralph

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Mar 2003 21:32:04 +0200 (EET)

> the interface to my home network.

That's not what I meant at all, the scope was "enterprise"; I acknowledge
your "unmanaged" case.
 
> it receives an RA with either or both of the 'M' and 'O' bits

RFC2461 6.2.7 gives some insight: nothing is done, based on the current 
specification (but doing something is not explicitly forbidden either).

---

From: Mika Liljeberg <[email-masked]>
Date: 13 Mar 2003 23:46:31 +0200

> it receives an RA with either or both of the 'M' and 'O' bits

RFC2462 states several times that routers are not expected to process
router advertisements.

	MikaL

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 14 Mar 2003 09:01:54 +0900

>the interface to my home network.

	i don't usually call a home router "NAS".  NAS usually refers to
	router equipment on the ISP side.

itojun

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 14 Mar 2003 01:35:18 -0800

>RFC2462 states several times that routers are not expected to process
RFC 2461, section 6.2.7 clearly does allow for routers processing router
advertisements, i.e., for consistency verification. It concludes by saying:

  "Any other action on reception of Router Advertisement messages by a
   router is beyond the scope of this document."

RFC 2462, section 4 says:

  "The remaining autoconfiguration steps are performed only by hosts; the
   (auto)configuration of routers is beyond the scope of this document."

So, it doesn't appear to me that either specification covers the case in
question.

Fred Templin
[email-masked]