Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-02.txt

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 6 Jul 2004 12:08:49 +0900 (JST)

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IP Version 6 Working Group Working Group of the
>  IETF.
> 
> 	Title		: IPv6 Stateless Address Autoconfiguration
> 	Author(s)	: S. Thomson, et al.
> 	Filename	: draft-ietf-ipv6-rfc2462bis-02.txt
> 	Pages		: 30
> 	Date		: 2004-6-17

	i guess it is under WG last call, but i could not find the annoucement
	so i respond to this message.

	i have objection to 5.4.5 "when duplicated address detection fails".
	the text suggest that hardware-address-based linklocal address fails
	on DAD test, "the interface SHOULD be disabled".

	first of all, what does it mean by "disable interface"?  if the
	interface has IPv4 addess and IPv4 packets are going through the
	interface, should we kill IPv4 as well?  what about AppleTalk?
	does "disable interface" require hardware disabled (turn IFF_UP to 0)
	or only software?

	moreover, even when DAD test fails for hardware-address-based linklocal
	address, there are number of routes we can take:
	- try again with random-number-generated linklocal address
	- beep beep, call operator
	- etc

	suggested change: replace "the interface SHOULD be disabled" by the
	following:
		the link-local address should be marked as "DAD failed",
		and further autoconfiguration SHOULD NOT be performed based
		on the link-local address (such as generation of global address
		using the interface ID on the link-local address).
		Operators (or operating system) SHOULD be consulted to correct
		the situation.

itojun

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 07 Jul 2004 17:29:26 +0900

>>>>> On Tue,  6 Jul 2004 12:08:49 +0900 (JST), 
>>>>> [email-masked] (Jun-ichiro itojun Hagino) said:

> 	first of all, what does it mean by "disable interface"?

Good question, but I guess we need to discuss more fundamental one
(below) first, so I'll make a separate response for this.

> 	- beep beep, call operator

I'd first like to revisit the discussion that led to the current
text of rfc2462bis.  If anyone who wants to join this particular
thread is not familiar with the past discussion, please first go
through it.

Christian Huitema started the previous discussion, which targeted the
original text of RFC2462 section 5.4.5:

  - http://www1.ietf.org/mail-archive/web/ipv6/current/msg00926.html

After some discussion, Thomas Narten clarified the original motivation
of the specification:

  - http://www1.ietf.org/mail-archive/web/ipv6/current/msg00949.html

I then proposed the current text of rfc2462bis based on the
clarification:

  - http://www1.ietf.org/mail-archive/web/ipv6/current/msg01514.html

Several people agreed on the change, including those who seemed to
have opposed to the idea of "disabling" the interface.  Hence the
current text is now in the wg last call.

The main point Thomas made is that DAD failure for an EUI-64 based
address is likely to indicate MAC address collision, in which case
disabling the entire interface is better rather than trying hopeless
recovery which may even make it harder to diagnose the real problem.
(I believe the current text of rfc2462bis clearly made the point, BTW)

In that sense, "try again with random-number-generated linklocal
address" doesn't make sense.  We could "call operator with a beep",
but we'd not be able to do that via network if the MAC address
collides.  So, IMO, it is not very convincing to argue we could rely
on such an outbound mechanism in a discussion about a network protocol
specification.

Meanwhile, we could also make a more fundamental question on whether
the analysis that Thomas provided (i.e., DAD failure for EUI-64 based
address probably means MAC collision) is valid.  If not, this can be
another reason to reconsider the current text.  I personally think
his analysis is quite reasonable though.

In any event, I understand this is a trade-off issue.  One can validly
support Thomas's analysis and argue that it's even better or safer to
disable the entire interface.  At the same time, others can validly
say it's overkilling.  So it's not surprising that we cannot get 100%
agreement on either side.  So far, it seems to me a majority of people
agreed on the current text with the rationale, and, while I'd respect
your concern, the points you provided do not seem to me strong
enough to reverse the decision.

Of course, I'm still open to others's opinions and/or further source
to reconsider the decision.

> 	suggested change: replace "the interface SHOULD be disabled" by the

Thanks for the suggestion, but I guess it's too early to discuss
specific change at the moment.  If we decide to change the past
decision, I'll come back to the proposal.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: [email-masked]
Date: Wed, 07 Jul 2004 17:38:29 +0900

>his analysis is quite reasonable though.

	today we are using Ethernet-based technology, hence EUI64 is generated
	by MAC address.  however we don't know what kind of technology we
	will be using for coming decade (it could be 10Tbase-TX, it could be
	something else, we just cannot predict).
	i personally think the analysis (by Thomas Narten) is short-sighted.

	moreover, if MAC address is under collision, IPv4 does not work,
	Appletalk does not work (i guess).  so there's no point in IPv6
	making a judgement call to disable *interface*.  it is like IPv6 is
	saying "i'm the law on this interface, other protocol must obey me".
	if it is to disable *the use of IPv6 on the interface*, or disable
	*the particular address which failed DAD*, it makes more sense.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 07 Jul 2004 17:43:46 +0900

> 	does "disable interface" require hardware disabled (turn IFF_UP to 0)

As I said in my previous response, I'll concentrate on this one in
this message.

I think this is a valid question, and rfc2462bis should clarify what
"disable" means (if we agree on the current decision on "disabling"
interface, of course).

Considering the original background is that DAD failure on an  
MAC address based L3 address likely means MAC address collision, the
"ideal" interpretation would be "disabling any operation of any
network protocols, including IPv4/AppleTalk/IPX/whatever".

At the same time, however, this is probably overkilling particularly
because we are basically only talking about a specific network
protocol (IPv6) in this specification, and this can be regarded as
protocol-boundary violation in that sense.

So, I personally think "disabling" only affects IPv6 network
operation.  I'd say disabling an interface means

- the node does not send any IPv6 packets on the interface
- the node silently discards any IPv6 packets, if any, received on the
  interface

This should usually mean "disabling" is performed as a software
operation, but it's an implementation-specific issue and will be out
of scope of the protocol specification document IMO.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 08 Jul 2004 11:55:59 +0900

>>>>> On Wed, 07 Jul 2004 17:38:29 +0900, 
>>>>> [email-masked] said:

> 	i personally think the analysis (by Thomas Narten) is short-sighted.

I respect the opinion, but I also think that kind of argument (i.e.,
we cannot tell future technologies, so we cannot do xxx) is too
generic (thus can always apply) to reverse this particular decision in
rfc2462bis.  (For example, we have a similar decision on the
"almost-fixed" prefix length of 64 for address autoconfiguration while
we cannot be sure about future link types.  But we'll probably not be
able to convince others to loosen the sense of the "almost constant"
by just saying "we cannot tell future link types on which the address
prefix length also depends, so the almost fixed number is
short-sighted")

Besides, the current text of rfc2462bis actually says "based on the
hardware address" instead of assuming EUI-64 unconditionally:

   If the address is a link-local address
   formed from an interface identifier based on the hardware address
   (e.g., EUI-64), the interface SHOULD be disabled.

I guess this wording already address your concern because the
description should mean a future link-layer technology can be an
exception to this rule if interface identifiers are not directly tied
with link-layer (hardware) addresses.  I added "EUI-64" as an example
because it would provide concrete idea on what the "hardware address"
actually means for implementors.  I think the current wording is
enough, but if you are still worried about future formats of EUI-64
that can be an exception, I could even say "(e.g., today's EUI-64
format for Ethernet links)".

> 	*the particular address which failed DAD*, it makes more sense.

I've already proposed to use the interpretation of limiting the
meaning of "disabling" to IPv6 operation.

So...can you live with the current specification of "disabling the
entire interface" if we limit the effect to IPv6 (and clarify that
point in the document)?

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 8 Jul 2004 14:04:42 +0900 (JST)

> format for Ethernet links)".

	yup, i know this.

> entire interface" if we limit the effect to IPv6 (and clarify that

	yes, that is what i want to see.  however, even in this case,
	"disable" has multiple interpretations:
	- disable the address which failed DAD
	- disable the address which shares the same interface ID as the
	  DAD-failed linklocal
	- disable the use of IPv6 (all addresses on the interface)

	i would like to see your clarified text and then i may comment.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 08 Jul 2004 14:29:41 +0900

>>>>> On Thu,  8 Jul 2004 14:04:42 +0900 (JST), 

> 	i would like to see your clarified text and then i may comment.

The last one (see also a previous message of mine in this thread -
attached below).  Or perhaps even more - for example, if a router
finds duplication on an interface, it won't forward packets to or from
that interface.  This scenario is not directly related to "addresses"
on the interface.

If we can agree so far, I'll make specific wording for the next
revision of rfc2462bis.

					JINMEI, Tatuya

Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-02.txt
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: [email-masked] (Jun-ichiro itojun Hagino)
Cc: [email-masked]
Date: Wed, 07 Jul 2004 17:43:46 +0900
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>

					JINMEI, Tatuya

---

From: [email-masked]
Date: Thu, 08 Jul 2004 14:32:08 +0900

>If we can agree so far, I'll make specific wording for the next

	ok, from the attached message, i can see which direciton you are going
	to.  i'll wait for the next revision.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 12 Jul 2004 19:51:48 +0900

>>>>> On Thu, 08 Jul 2004 14:32:08 +0900, 
>>>>> [email-masked] said:

> 	to.  i'll wait for the next revision.

The proposed revised text (the entire Section 5.4.5) is attached
below.  Is this acceptable?

					JINMEI, Tatuya

5.4.5  When Duplicate Address Detection Fails

   A tentative address that is determined to be a duplicate as described
   above MUST NOT be assigned to an interface and the node SHOULD log a
   system management error.

   If the address is a link-local address formed from an interface
   identifier based on the hardware address (e.g., EUI-64), IPv6
   operation on the interface SHOULD be disabled.  By disabling IPv6
   operation, the node will then

   -  not send any IPv6 packets from the interface
   -  silently drop any IPv6 packets received on the interface
   -  not forward any IPv6 packets to the interface (when acting as a
      router or processing a packet with a Routing header)

   In this case, the IP address duplication probably means duplicate
   hardware addresses are in use, and trying to recover from it by
   configuring another IP address will not result in a usable network.
   In fact, it probably makes things worse by creating problems that are
   harder to diagnose than just disabling network operation on the
   interface; the user will see a partially working network where some
   things work, and other things will not.

   On the other hand, if the duplicate link-local address is not formed
   from an interface identifier based on the hardware address, IPv6
   operation on the interface MAY be continued.

---

From: [email-masked]
Date: Tue, 13 Jul 2004 10:23:01 +0900

>below.  Is this acceptable?

	basically i'm happy with the text.  one thing boggles me is that
	the term "based on the hardware address" implicitly means "uniquely
	assigned hardware address", like MAC address, in the text.  hardware
	address may or may not be uniquely assigned (depending on underlying
	technology we will be using).  i'd love to see it clarified.

itojun

>   identifier based on the hardware address (e.g., EUI-64), IPv6	<---
>   hardware addresses are in use, and trying to recover from it by	<---
>   from an interface identifier based on the hardware address, IPv6	<---

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 13 Jul 2004 18:35:14 +0900

>>>>> On Tue, 13 Jul 2004 10:23:01 +0900, 
>>>>> [email-masked] said:

> 	technology we will be using).  i'd love to see it clarified.

The simplest resolution would be to add a qualifier like this:

   If the address is a link-local address formed from an interface
   identifier based on the hardware address which should be uniquely
   assigned (e.g., EUI-64 for an Ethernet interface), IPv6
   operation on the interface SHOULD be disabled.

and to modify the 3rd part accordingly:

   On the other hand, if the duplicate link-local address is not formed
   from an interface identifier based on the hardware address which
   should be uniquely assigned, IPv6 operation on the interface MAY be
   continued.

>> configuring another IP address will not result in a usable network.

Makes sense?

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 14 Jul 2004 04:56:40 +0900 (JST)

>    should be uniquely assigned, IPv6 operation on the interface MAY be

	s/should be/should have been/ ?  (not sure)

> >> configuring another IP address will not result in a usable network.

	yup.  thanks.

itojun

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 14 Jul 2004 21:41:14 +0900

>>>>> On Wed, 14 Jul 2004 04:56:40 +0900 (JST), 

> 	s/should be/should have been/ ?  (not sure)

or "which is supposed to be uniquely assigned"?

I don't have a particular preference, but I'll use the last one if no
one else has a preference either.

					JINMEI, Tatuya