Jinmei,
>
> 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.)
>
I follow the motivation but....
It seems to me that you are trying to solve a problem of your own making.
You say that you want to specify P/64 so that you don't have to explicitly
configure the address of the other end of the point-to-point link. I
understand why you would want to do this.
However, you then say that you don't want to use the standard mechanisms
which have been developed for dealing with this case. That is, sending a
NS and receiving an NA. You say that this is because you don't want to
drop packets during the resolution phase but I don't understand how this is
any different than configuring P/64 on an Ethernet. You say that the NS/NA
isn't necessary but in fact it is. By specifying the P/64 you need some
sort of discovery to determine what address(es) are on the other side
of the link. Your special case icmp6 error is just using a negative
acknowledgement to achieve the discovery.
It seems to me that we shouldn't be adding more complexity to handle a
case which is already handled by the existing discovery mechanisms.
It seems to me that there are two choices:
1) Specify P/128 on the link. No discovery required but the address of
the other end of the link must be known explicity.
2) Specify P/n where n is less than 128. Use the existing ND/NA mechanism
to determine reachability of the destination that falls within the P/n
prefix.
I am sure that this is counter to the way a number implementations work
today, including ours I think, but I don't really see why one would want to
invent some other way to deal with basic neighbor discovery functions.
Just my $.02
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
