No, but I think it would be worthwhile to find out what real implemenations
do. Unless an IETF standard has specific RFC 2119 languge in it, your milage
can vary.
jak
----- Original Message -----
From: "Templin, Fred L" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>; "Julien Laganier"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "INT Area" <[EMAIL PROTECTED]>; "IETF IPv6 Mailing
List" <[email protected]>
Sent: Thursday, August 31, 2006 2:07 PM
Subject: RE: [netlmm] Multilink Subnet Considerations for NETLMM Addressing
(removing other WGs than NETLMM)
The default behavior (see
Section 5.2) when sending a packet to an address for which no
information is known about the on-link status of the address is to
forward the packet to a default router;
i.e. send packets to the default router.
This does not prevent a node from sending an NS for an address that
the node
suspects is on link, even if the prefix indicates that it might not
be, and
receiving a reply, then routing directly to that node. It also does
not
prevent a node from sending an NS for a link local address that it
suspects
is on the link and receiving a reply, then routing directly, even
though the
global address looks as if isn't. It is basically up to the
implementation
whether this would work or not. This could cause applications to break
if
they make the assumption that they can do this, then they are used on
a
NETLMM network. The result would be an interoperability problem, which
is
what IETF standards are supposed to prevent.
Yes, an implementation that ignores the default behavior and tries
to contact a peer whose on-link status is unkown via direct NS/NA
could learn that the peer is an on-link neighbor for the moment.
But, it has no guarantee that the peer will remain on-link for
even one second beyond the receipt of the NA.
Ignoring the default behavior in this case seems like risky
practice in any environment and not particular to NETLMM.
Are you aware of implementations that do this?
Fred
[EMAIL PROTECTED]
_______________________________________________
netlmm mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/netlmm
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
