Subject: clarification needed on draft-ietf-ipv6-rfc2011-update-01.txt

From: "Qing Li" <[email-masked]>
Date: Wed, 20 Nov 2002 20:07:07 -0800

Please help me clarify the consequences of a SET operation
	on the "ipv6InterfaceAdminStatus" specified in this draft, and
	its relation to RFC2461 and RFC2462.

	In RFC2462 section 5.3 , "A node forms a link-local address whenever an
	interface becomes enabled. An interface may become enabled after any
	of the following events: ... The interface becomes enabled by system
	management after having been administratively disabled."

	So my reading on this is that when "ipv6InterfaceAdminstatus"
	is SET to down (2) then up (1), stateless autoconfig is restarted
	and DAD is performed again.

	In RFC2461 section 7.2.6, however, it states "In some cases a node
	may be able to determine that its link-layer address has changed
	(e.g. hot-swap of an interface card) and may wish to inform its neighbors
	of the new link-layer address quickly. ..."

	I think these 2 paragraphs are somewhat in conflict with each other.
	The time it takes for the host to detect the change in LLAddr
	is indeterminate. During this period some other host might have
	claimed the addresses that are in use. So I think DAD should be restarted
	when the host detects a change in LLAddr.

	If the interface is shutdown through ipv6InterfaceAdminstatus, or if the
	host detects a downed interface, my questions are:

	1. What happens to the prefixes learned over that interface?

   	   If I were to toss the prefixes immediately then consequently I will
be
	   invaliding my assigned addresses. This will invalidate all of my TCP
	   connections, too. So I probably would want to keep these around
	   until the lifetime expires.

	   On the other hand I would need to do something so that new
	   connection would not use any address configured out of
 	   those prefixes.

	2. Should the prefix routes be removed or marked as unusable?

	   I think the prefix routes should be marked as unusable instead
	   removal because of the lifetimes associated with them.

	3. Should the neighbor cache be flushed?

	-- Qing

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