Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

[HYUN WOOK CHA <hyunwook.cha at samsung.com>]

Hello, Thomas Narten and 6MAN folks.

I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at the 6MAN session in Dublin IETF. This draft aims to clarify the handling of the M/O flags of IPv6 RA. Though I got several comments during my presentation, I could not figure out what you really pointed out. So, I decided to ask you again why you think that the issues which the draft addresses are neither clear nor considered as worthy to be discussed in the 6MAN wg. 
First of all, I would like to give a brief summary for the draft. 
Existing specification (RFC2462) does not give a method on how to revoke DHCPv6 clients once they were invoked by the M or O flags of RA messages. Let us think about the case that a administrator wants to change network policy from stateful addressing via DHCPv6 to stateless one. Although the admin clears M flag of RA messages and reconfigure(or shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even after all bindings expire and stateful addresses are invalidated, the client will keep searching another stateful servers by sending SOLICITs, because the DHCPv6 protocol does not care about values From ipv6-bounces at ietf.org  Thu Aug 21 18:07:35 2008
Return-Path: <ipv6-bounces at ietf.org>
X-Original-To: ipv6-archive at megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EDBF728C14E;
	Thu, 21 Aug 2008 18:07:34 -0700 (PDT)
X-Original-To: ipv6 at core3.amsl.com
Delivered-To: ipv6 at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9109328C14E;
	Thu, 21 Aug 2008 18:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.325
X-Spam-Level: 
X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=1.486, 
	BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041,
	MIME_BASE64_TEXT=1.753, 
	RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id sD8wuHxTaPti; Thu, 21 Aug 2008 18:03:53 -0700 (PDT)
Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25])
	by core3.amsl.com (Postfix) with ESMTP id 656053A68A4;
	Thu, 21 Aug 2008 18:03:53 -0700 (PDT)
Received: from ep_ms7_bk (mailout2.samsung.com [203.254.224.25])
	by mailout2.samsung.com
	(iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004))
	with ESMTP id <0K5Z00LP59KVKA at mailout2.samsung.com>; Fri,
	22 Aug 2008 10:02:55 +0900 (KST)
Received: from ep_spt04 (ms7.samsung.com [203.254.225.101])
	by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14
	2004)) with ESMTP id <0K5Z000VZ9KUT6 at ms7.samsung.com>; Fri,
	22 Aug 2008 10:02:55 +0900 (KST)
Content-return: prohibited
Date: Fri, 22 Aug 2008 01:02:54 +0000 (GMT)
From: HYUN WOOK CHA <hyunwook.cha at samsung.com>
Subject: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"
To: narten at us.ibm.com, ipv6 at ietf.org, volz at cisco.com, dhcwg at ietf.org
Message-id: <7182010.12431219366974773.JavaMail.weblogic at epml09>
MIME-version: 1.0
MIME-version: 1.0
X-Priority: 3
Msgkey: 20080821232623868 at hyunwook.cha
X-MTR: 20080821232623868 at hyunwook.cha
X-EPLocale: ko_KR.euc-kr
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale: 
X-EPHeader: ML
X-EPTrCode: 
X-BeenThere: ipv6 at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: hyunwook.cha at samsung.com
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>,
	<mailto:ipv6-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces at ietf.org
Errors-To: ipv6-bounces at ietf.org


Hello, Thomas Narten and 6MAN folks.

I made a presentation for our draft "draft-cha-ipv6-ra-mo-00.txt" at the 6MAN session in Dublin IETF. This draft aims to clarify the handling of the M/O flags of IPv6 RA. Though I got several comments during my presentation, I could not figure out what you really pointed out. So, I decided to ask you again why you think that the issues which the draft addresses are neither clear nor considered as worthy to be discussed in the 6MAN wg. 
First of all, I would like to give a brief summary for the draft. 
Existing specification (RFC2462) does not give a method on how to revoke DHCPv6 clients once they were invoked by the M or O flags of RA messages. Let us think about the case that a administrator wants to change network policy from stateful addressing via DHCPv6 to stateless one. Although the admin clears M flag of RA messages and reconfigure(or shutdown) the DHCPv6 server, the DHCPv6 clients keep operating. Even after all bindings expire and stateful addresses are invalidated, the client will keep searching another stateful servers by sending SOLICITs, because the DHCPv6 protocol does not care about values of RA flof RA flags. If the intention of the restriction that DHCPv6 clients should be invoked at the transition from FALSE to TRUE of the M or O flag of RA is that waste of resources of network infrastructure and host devices caused by useless DHCPv6 operation can be prevented and stateful addresses can be configured automatically by the administrative policy, we believe that our draft has value to supplement missing parts which existing specification and implementations have. 
The second issue (which is likely less important) is concering conflicts M/O flags from different routers which belongs to differnt administrative domains. Existing IPv6 stack implementations such as linux are assumed to comply with handling of the M/O flags of RA in the RFC2462. So, they just keep the most recent M/O values without considering senders of RA messages. This point does not expose serious problems though it does not provide consistent informations about the availability of the DHCPv6 service. Since we would like to support revocation of DHCPv6 clients at the transition of M or O flag from TURE to FALSE, the handling of the flags is reworked in our draft to avoid the iteration of invoking and revoking of the clients.
Because we believe that the issues are obvious and clear, we would like to ask why 6MAN folks do not agree with our points.
Please give your opinions.

Thank you in advance. 

Joseph HyunWook Cha

Software Engineer 
Network System Division 
SAMSUNG Electronics, Inc.

  If you do not stand firm in your faith, 
  you will not stand at all.  - Isaiah 7:9
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


ags. If the intention of the restriction that DHCPv6 clients should be invoked at the transition from FALSE to TRUE of the M or O flag of RA is that waste of resources of network infrastructure and host devices caused by useless DHCPv6 operation can be prevented and stateful addresses can be configured automatically by the administrative policy, we believe that our draft has value to supplement missing parts which existing specification and implementations have. 
The second issue (which is likely less important) is concering conflicts M/O flags from different routers which belongs to differnt administrative domains. Existing IPv6 stack implementations such as linux are assumed to comply with handling of the M/O flags of RA in the RFC2462. So, they just keep the most recent M/O values without considering senders of RA messages. This point does not expose serious problems though it does not provide consistent informations about the availability of the DHCPv6 service. Since we would like to support revocation of DHCPv6 clients at the transition of M or O flag from TURE to FALSE, the handling of the flags is reworked in our draft to avoid the iteration of invoking and revoking of the clients.
Because we believe that the issues are obvious and clear, we would like to ask why 6MAN folks do not agree with our points.
Please give your opinions.

Thank you in advance. 

Joseph HyunWook Cha

Software Engineer 
Network System Division 
SAMSUNG Electronics, Inc.

  If you do not stand firm in your faith, 
  you will not stand at all.  - Isaiah 7:9
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------