Subject: new revision of rfc2462bis is available

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 10 Feb 2004 21:38:51 +0900

I've submitted a new revision of the rfc2462bis draft:
draft-ietf-ipv6-rfc2462bis-00.txt

I expect a certain amount of delay before the draft is ready at the
official I-D archive, so I put a copy of the draft at the following URL:

http://www.jinmei.org/draft-ietf-ipv6-rfc2462bis-00.txt

Any comments/questions/corrections are welcome.

Thanks,

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

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

---

From: Felipe Alfaro Solana <[email-masked]>
Date: Tue, 10 Feb 2004 20:56:12 +0100

> Any comments/questions/corrections are welcome.

May I ask a question about the following paragraph?

   o  Small sites consisting of a set of machines attached to a single
      link should not require the presence of a stateful server or
      router as a prerequisite for communicating.  Plug-and-play
      communication is achieved through the use of link-local addresses.
      Link-local addresses have a well-known prefix that identifies the
      (single) shared link to which a set of nodes attach. A host forms
      a link-local address by appending its interface identifier to the
      link-local prefix.

I don't understand how is it possible for two hosts to communicate when
no stateful server or router advertising a prefix is attached to the
link. In this case, both hosts are configured exclusively with
link-local addresses, but since those addresses have a fe80::/10 prefix,
how can the IPv6 stack know what interface should the packets be sent
on?

For instance, on Linux 2.6 kernels, when trying to ping another host
using its link-local IPv6, an invalid argument error is generated since
the kernel is not able to guess which interface the packet should be
sent to, since any local interface has exactly the same prefix and
length. This gets complicated even more if the machine has multiple
interfaces, for example, two Ethernet interfaces.

I thought that two IPv6-enabled hosts could only communicate if both
have a site-local or global IPv6 address configured.

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Feb 2004 00:07:39 +0000

> draft-ietf-ipv6-rfc2462bis-00.txt

on the issue of DAD and loopback suppression outlined in appendix A.

I've seen a couple of cases in the past where DAD packets could be
looped back by the network. this could happen if there is a temporary
loop in a bridged network. I've also seen it where parallel links are
used between two boxes, e.g Etherchannel.

this is something which is very difficult to solve with the current
spec. the only alternative is to filter out DAD packets with the same
link-layer address as the receiving interface. stopping duplicate MAC
address checking from working.

one solution could be to add a optional identifier option to DAD NS
packets, so that the sender can recognise the case when its own
packets are looped around.

too big a change for 2462bis?

/ot

---

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

>>>>> On Thu, 12 Feb 2004 00:07:39 +0000, 
>>>>> Ole Troan <[email-masked]> said:

> too big a change for 2462bis?

I think this is too big to merge into 2462bis (sorry), but I agree
this is worth considering as an extension in a separate document
(depending on how this is popular and severe).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2004 15:35:33 +0900

>>>>> On Tue, 10 Feb 2004 20:56:12 +0100, 
>>>>> Felipe Alfaro Solana <[email-masked]> said:

> how can the IPv6 stack know what interface should the packets be sent

Just because link-local addresses has a well-known prefix fe80::/10
cannot be the source of the problem.  The problem is that link-local
addresses are only unique within a single link and are ambiguous for
a multi-linked host.  If the host in question has only one physical
interface to which it is connected to the link and the interface is
specified as "the default" (see draft-ietf-ipv6-scoping-arch-00.txt
for more details on this), link-local addresses work just like global
addresses.  Even if the default interface is not specified, link-local
addresses will still work when the user specified the correct link
(interface) (again, see the scoping-arch draft for details).

> interfaces, for example, two Ethernet interfaces.

This is just an implementation.  For example, *BSDs have the notion of
the "default interface" (and the default link automatically derived
from the interface) to implement the scope-arch draft, with which the
above scenario works perfectly.

So,

> have a site-local or global IPv6 address configured.

this is not really correct.  Also, site-local addresses even have the
same problem of ambiguity.  And besides, the IETF is now going to kill
site-local addresses.  Let's just concentrate on link-local and global.

					JINMEI, Tatuya

---

From: Ole Troan <[email-masked]>
Date: Thu, 12 Feb 2004 20:19:45 +0000

> This essentially the problem with DAD on wifi, right?  That should
> make a general solution more interesting then just a corner case.

no, this is a general problem. I've seen this on Ethernet.

I've spoken to the DAD/WIFI draft owners and we've agreed to add the
id option to that draft and rename it to something less wifi specific.

/ot

---

From: Michael Hunter <[email-masked]>
Date: Thu, 12 Feb 2004 12:09:40 -0800

On Thu, 12 Feb 2004 14:41:09 +0900

			mph

---

From: Greg Daley <[email-masked]>
Date: Fri, 13 Feb 2004 10:37:55 +1100

Hi Ole,

I think the problem is half solved with securing-neighbour discovery.

> id option to that draft and rename it to something less wifi specific.

SEND has already defined a random Nonce option for
Neighbour Solicitation messages.

Also defined are Timestamp options for these messages.

Send requires both of these to be present in a DAD-NS.

In this case, a node can keep track of (only) its fresh Nonces,
and it will be able to check if received DAD NS's are
its own.

These options would even be able to be used in non-SEND
solicitations under the constraint that there's no trust
associated with them (since they're not signed messages).

There's no further identifier definition required (although
it would be valuable to write a short draft on it).

Greg Daley

---

From: Ole Troan <[email-masked]>
Date: Fri, 13 Feb 2004 11:28:54 +0000

Greg,

> it would be valuable to write a short draft on it).

thanks for pointing out the SEND draft to me, I haven't followed that
work for a while.

yes, it seems that the Nonce option should work. a SEND node receiving
these would interpret this message as a unsecured message as long as
there is no trust association, right? if there is a trust association
the message would be silently discarded.

agree, that a short draft on how non-SEND nodes can use these options
is needed.

cheers,
Ole

---

From: Greg Daley <[email-masked]>
Date: Mon, 16 Feb 2004 11:55:46 +1100

Hi Ole,

> the message would be silently discarded.

I believe that the messages aren't interpreted as
'secured' unless they have a valid signature.
(the key used to verify the signature is often included
in the SEND message).

For DAD-NS/NA messages though, there's likely to be no
existing relationship between the configuring node and
a receiver.  The SEND message in and of itself typically
provides enough information to prove its ownership of a
public key (and thus an address if CGA is used).

This doesn't actually mean that unsecured DAD messages
get silently discarded though.  For the first DAD attempt,
SEND actually allows unsecured NA's to indicate address
duplication (though subsequent address configurations only
listen to SEND).

> agree, that a short draft on how non-SEND nodes can use these options

The shorter, the better...

Greg