Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard

Ralph Droms <rdroms@cisco.com> Thu, 20 November 2003 14:27 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05671 for <dhcwg-archive@odin.ietf.org>; Thu, 20 Nov 2003 09:27:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpm5-00051R-T4 for dhcwg-archive@odin.ietf.org; Thu, 20 Nov 2003 09:27:13 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKERD5e019301 for dhcwg-archive@odin.ietf.org; Thu, 20 Nov 2003 09:27:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpm5-00051D-PZ for dhcwg-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:27:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05600 for <dhcwg-web-archive@ietf.org>; Thu, 20 Nov 2003 09:27:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpm4-0003fq-00 for dhcwg-web-archive@ietf.org; Thu, 20 Nov 2003 09:27:12 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpm3-0003fn-00 for dhcwg-web-archive@ietf.org; Thu, 20 Nov 2003 09:27:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpls-0004zj-QM; Thu, 20 Nov 2003 09:27:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMplq-0004zU-0E for dhcwg@optimus.ietf.org; Thu, 20 Nov 2003 09:26:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05593; Thu, 20 Nov 2003 09:26:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMplo-0003fF-00; Thu, 20 Nov 2003 09:26:56 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMpln-0003dw-00; Thu, 20 Nov 2003 09:26:55 -0500
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 06:26:58 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEQMw5006221; Thu, 20 Nov 2003 06:26:23 -0800 (PST)
Received: from rdroms-w2k01.cisco.com (rtp-vpn1-332.cisco.com [10.82.225.76]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED18524; Thu, 20 Nov 2003 09:26:21 -0500 (EST)
Message-Id: <4.3.2.7.2.20031120092059.01ead240@flask.cisco.com>
X-Sender: rdroms@flask.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 20 Nov 2003 09:26:18 -0500
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] Re: Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard
Cc: iesg@ietf.org
In-Reply-To: <4.3.2.7.2.20031113213303.026f0448@flask.cisco.com>
References: <Pine.LNX.4.44.0311131608170.3196-100000@netcore.fi> <4.3.2.7.2.20031113074713.01e59b18@flask.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>

In response to comments from Pekka about the description of the function of
relay agents in providing stateless DHCPv6 service, is there any objection
to adding the following paragraph as the last paragraph in section 3,
"Overview", of draft-ietf-dhc-dhcpv6-stateless-02.txt:

   This document does not apply to the function of DHCPv6 relay agents as
   described in RFc 3315.  A network element can provide both DHCPv6 
service to
   some clients, while relaying messages for other clients to another DHCPv6
   server.  For example, a network element can provide stateless DHCPv6 
service
   to hosts requesting stateless DHCP service, while relaying messages from
   hosts requesting address assignment through DHCPv6 to another DHCPv6 server.

- Ralph

At 08:05 AM 11/14/2003 -0500, Ralph Droms wrote:
>At 04:13 PM 11/13/2003 +0200, Pekka Savola wrote:
> >On Thu, 13 Nov 2003, Ralph Droms wrote:
> > > Pekka - thanks for your review.  My responses to your comments are 
> inline.
> >
> >Thanks.. just a few responses inline.
> >
> >(Btw -- does the case I mentioned off-line about first-hop router being a
> >stateless DHCP server, but acting as DHCP relay for stateful DHCP need to
> >be explicitly mentioned -- I guess so?)
>
>Recognizing that a network element can be both a server and a relay
>agent has evolved in DHCPv4 without any explicit text - there's nothing
>in the DHPCv4 specifications that disallows such behavior.
>
>If there is consensus that text allowing a network element to act
>as both a DHCPv6 server and relay agent would be useful, we can add
>it to this doc...
>
> > > At 02:27 PM 11/3/2003 +0200, Pekka Savola wrote:
> > > >On Thu, 30 Oct 2003, The IESG wrote:
> > > >1) the spec is not sufficiently clear how the relays behave in a mixed
> > world
> > > >of stateless/stateful DHCP service.  That is, would deploying a
> > > >stateless-only relay (if such a thing is possible?) harm the 
> stateful DHCP
> > > >clients?  Is the implementation of a relay any different for
> > full/stateless
> > > >DHCP service, etc. ?:
> > > >
> > > >    The operation of relay agents is the same for stateless and stateful
> > > >    DHCPv6 service.  The operation of relay agents is described in the
> > > >    DHCPv6 specification.
> > >
> > > The functions referenced in draft-ietf-dhc-dhcpv6-stateless-01.txt are
> > > all completely defined in RFC 3315.  From the point of view of the
> > > DHCPv6 relay agent, there is no difference between the subset of
> > > RFC 3315 referred to as "stateless DHCPv6" and the full set of
> > > functions in  RFC 3315.
> > >
> > > More concisely, there are just "DHCPv6 relay agents" that work with both
> > > full RFC 3315 clients and stateless-only clients...
> >
> >Right.  I think this should be spelled out in the stateless document a bit
> >better, that the stateless DHCP has to implement "full" relay service,
> >which is of course rather lightweight in itself (it has no state, I
> >believe).
>
>I would rather add text like:
>
>    This document does not apply to the behavior of DHCPv6 relay agents.
>
> > > >==> that is, do relays really *flood* these messages to all the DHCPv6
> > > >servers they know, so that if one doesn't process the request but 
> silently
> > > >ignores it, the others can step up and handle the job?  See also the 
> point
> > > >1) above.
> > >
> > > Yes, a relay agent forwards a copy of each message it receives from a
> > client
> > > to each of the servers in its configured list of servers.
> >
> >Are all the responses equally flooded back to the relay as well?
>
>Yes - in this regard a DHCPv6 relay agent works the same as a
>DHCPv4 relay agent.
>
> >   Does the
> >relay pick and respond to the hosts with first or all the information?
> >
> >(Just trying to clarify, this probably doesn't need changes in the spec.)
>
>No.
>
> > > >    1-4:   give an introduction to DHCPv6 and an overview of DHCP 
> message
> > > >       flows
> > > >
> > > >==> some of those flows are redundant to Stateless DHCPv6 operation,
> > > >though.. :-)
> > >
> > > OK, would a more precise list (e.g., individual subsections rather than
> > > simply "1-4") be helpful?
> >
> >That might not hurt.  However, what I was referring to was that e.g.
> >"message flows" or sections like do not really reflect the stateless DHCP
> >operation...
>
>OK.
>
>- Ralph
>
> >--
> >Pekka Savola                 "You each name yourselves king, yet the
> >Netcore Oy                    kingdom bleeds."
> >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg