Like I said, unless the RFC says "MUST", your milage may vary. People often
have all kinds of reasons to ignore recommendations that aren't required.
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:23 PM
Subject: RE: [netlmm] Multilink Subnet Considerations for NETLMM Addressing
What would you expect from implementations that ignore the
default behavior specified in the RFCs and ignore the advice
they receive in the form of PIOs with 'L' set to 0 in RAs?
I believe that hosts should be intelligent, but not to the
point that they presume they know better than what the
network is telling them w/o better information. Its not
about smart hosts vs smart networks; its about finding
proper balance.
Fred
[EMAIL PROTECTED]
-----Original Message-----
From: James Kempf [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 31, 2006 2:17 PM
To: Templin, Fred L; Julien Laganier
Cc: [EMAIL PROTECTED]; INT Area; IETF IPv6 Mailing List
Subject: Re: [netlmm] Multilink Subnet Considerations for NETLMM
Addressing
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
