I don't think that analogy is quite accurate, from an official, RFC 2119
standards language viewpoint.
Saying something is default is like saying "You shouldn't go beyond this
point because there is a possibility of a life threatening situation".
Saying "this MUST not be done" is like saying "Do not go beyond this point
or YOU WILL DIE".
In the first case, some adverturesome person might decide the risk is worth
it. In the second, only a fool would try it.
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 3:02 PM
Subject: RE: [netlmm] Multilink Subnet Considerations for NETLMM Addressing
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
