>>>>> On Tue, 01 May 2001 17:25:17 +0700,
>>>>> Robert Elz <[EMAIL PROTECTED]> said:
> | to throw out ripng packets to the other end, we would need to have
> | fe80::%interface/64 as well as ff02::%interface/64 to be installed
> | onto the routing table.
> "Need to have fe80::%interface/64" ?? Why?
(Although here seems to be a mixture of an implementation issue and a
protocol issue,) you're right, we do not need fe80::%p2plink/64 to
send multicast RIPng packets on the p2p link (I intentionally changed
the scope ID part from "interface" to "p2plink").
[As for the implementation, we do not even need ff02::%p2plink/64 to
send the packets, since our routing daemons usually specify the
outgoing *interface* using the advanced API...but this is a completely
different issue.]
In my understanding, our (KAME's) motivation is as follows:
1. we'd like to allow users to configure a /64 prefix even on a p2p
link (the prefix might be link-local, site-local, or global. That
doesn't really matter in this discussion.)
2. we'd also like to allow users to use the /64 prefix on the p2p link
just like an ethernet (i.e. broadcast) link. That is, when P/64 is
assigned to the link, users can assume there might be a node P:A on
the other end of the link for an arbitrary interface ID 'A', which
might be learned from DNS, off-line communication, some other
discovery mechanism, or even some misconfiguration or attacks.
3. the only difference between broadcast links and p2p links is that we
do not need the (link-layer) address resolution procedure on a p2p
link. Thus, when a user specifies a P:A as destination, the kernel
can simply send a packet to an interface of the link, and the
interface is uniquely determined in typical configurations (i.e. the
only interface that attaches to the link).
4. however, this "optimization" of sending rule would raise the
possibility that the other node receives a pakcet destined to an
address that the node does not have (but that covers the prefix
which should be regarded as on-link on the p2p link). In this case,
the packet would be looped on the link, consuming its hop-limit.
5. in fact, we've seen many such loops in our IPv6 backbone (as itojun
described,) and wondered if we could add another kind of
optimization for the forwarding rule.
As someone on the list pointed out, we could do NS-NA exchange on the
step 3 instead of just sending the packet. However, we did not like
this approach because it could drop some packets during the
"resolution" period, or at least could delay the arrival of the
packet, while such drops and delay should not really be necessary.
My opinion is that this type of forwarding optimization (i.e. dropping
the packet and sending an icmp6 error instead of letting the packet be
looped) is worth considering, although it might not always be the best
choice (e.g. when someone wants to send a packet assuming that it
should be looped back for testing purposes).
So, how about specifing this as a "SHOULD be enabled by default, but
MUST be able to be configurable" stuff? (And the default behavior
might be controversial.)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
