Subject: Re: nonexisting destination on p2p link

From: Tim Hartrick <[email-masked]>
Date: Tue, 1 May 2001 16:08:45 -0700 (PDT)

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

---

From: [email-masked]
Date: Wed, 02 May 2001 09:24:35 +0900

>acknowledgement to achieve the discovery.

	when there's linklayer address defined for the particular L2,
	we don't do NS/NA (from the spec).  please imagine ppp, or rfc1933
	tunnels.  do you think it reasonable to run NS/NA in that case?
	then, what kind of changes are necessary to NS/NA?

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 May 2001 14:21:53 +0200 (CEST)

> 	then, what kind of changes are necessary to NS/NA?

Assuming we want to do this (which isn't clear to me yet), I don't think 
there are any changes needed
to the packet formats and processing rules in RFC 2461.
One question is whether such a NS should be multicast to the solicited node
multicast address or unicast to the solicited address.
Using multicast might be easier to implement since it follows the model
for a broadcast medium more closely.

  Erik

---

From: [email-masked]
Date: Wed, 02 May 2001 21:29:42 +0900

>for a broadcast medium more closely.

	for example, RFC2461 7.2.4 1st paragraph does not really fit nicely
	with L2 without linklayer address.  the rule for attaching
	target link-layer address option does not talk about cases on L2
	without link-layer address.
	the text is very cryptic for non-english speaker like me, i really need
	a machine-readable rulesets :-)

>   in order for the solicitation to have been received.  If the
>   solicitation's IP Destination Address is a multicast address, the
>   Target Link-Layer option MUST be included in the advertisement.

	now, we MUST attach a target link-layer address option in this case,
	but how?  there will be a lot more examples like this.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 2 May 2001 14:36:45 +0200 (CEST)

> 	with L2 without linklayer address. 

And it doesn't match the statements in section 4.3 and 4.4 which say when
the link-layer address options must and should be included.
Those statements have the global exceptions for link-layers that don't
have link-layer addresses.
However, when editing the document the text got too unreadable if those
exceptions where included everywhere where they apply.

> the rule for attaching

It's machine readable - my computer can parse the ascii charcters and
display them on the screen just fine.
Perhaps you mean machine executable? :-)

  Erik