A good friend likes to use an anecdote about ignoring advice. At the top of Yosemite Falls, there a sign that says: "Do not go beyond this point or YOU WILL DIE" (by falling 3000ft to the base of the falls below). Sadly, many people have done just that. Its not about laws; its about common sense.
Fred [EMAIL PROTECTED] -----Original Message----- From: James Kempf [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 2:59 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 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
