think your argument would work, though, if we
were discussing SHOULD versus MAY.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
profiles by requiring what isn't
necessarily required.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
to secure it.
No ... it means that if you have any common security mechanism, then
you need to provide a single common one. Providing more than one is
not as good, but, clearly, providing zero is reasonable provided that
you _know_ nobody will use it anyway.
--
James Carlson, Solaris Networking
Thomas Narten writes:
Thus, continuing to mandate IPsec (while continuing to punt on key
management) just looks silly.
Indeed. It's a solution out looking for a problem.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W
contingent
wants.
(And, really, the lack of mandated key management does make even the
SHOULD language a bit of a farce, as Thomas Narten has correctly
observed. You're not really getting any security goodness by
implementing a fraction of the bits needed for a real solution.)
--
James Carlson
assignment of 004f.
(When we talked, I thought we were talking strictly about the history
of the assignment, and I should have noted that at least going
forward, it's dead.)
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W
an implementation of it, I think losing that one reference would be a
step in the right direction. It serves only to send readers off into
the weeds.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02
Iljitsch van Beijnum writes:
On 13 nov 2007, at 13:46, James Carlson wrote:
works. (Such as the shim6 REAP protocol is designed to do although
REAP doesn't know about routes.) So it should clearly be possible to
send packets that don't conform to the source address / route
alignment
packet routing decisions based on the source address.
Perhaps that's not exactly the same as source routing used in other
contexts, but for the first hop, it's the same thing.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W
Manfredi, Albert E writes:
-Original Message-
From: James Carlson [mailto:[EMAIL PROTECTED]
I don't agree that those OSes screw up royally. They are, in fact,
doing what their users *tell* them to do.
If an application binds the source address on Subnet B and then sends
. The
dibbler project DHCPv6 client and server have been available for
several years, as well.
DHCPv6 client-side support integrated into Solaris back in January
2007. The first update release with it went out last month.
--
James Carlson, Solaris Networking [EMAIL PROTECTED
IETF Consensus as well.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Templin, Fred L writes:
I would be interested to know who has implemented and/or
is using DHCPv6 prefix delegation (RFC3633), because I'm
seeing some interesting use cases for it.
Yep. And I know I haven't implemented it. ;-}
--
James Carlson, Solaris Networking [EMAIL
service from other routers on the same link. They're also
still free to use link-local scope IPv6 on the link.
And it'd probably take the threat of violence to prevent them from
using manually-configured addresses (even global scope ones) if they
so choose.
--
James Carlson, Solaris Networking
Jun-ichiro itojun Hagino writes:
ranti wonder how many of those who are voicing opinion here are
actually using IPv6 in a daily basis./rant
I am. Does that help?
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W
David W. Hankins writes:
On Wed, Aug 15, 2007 at 10:33:16AM -0400, James Carlson wrote:
and it needs to be able to Confirm the use of
addresses, which it may not have allocated.
That doesn't make sense to me. The DHCPv6 Confirm message is for
confirming an address lease
, knowing the addresses of the machines on the
customer's network is useless, as it doesn't tell you the address of
that CPE router.
Obvious sorts of ways to get this would be to keep track of your
delegations or (alternatively) use an appropriate routing protocol.
--
James Carlson, Solaris
Iljitsch van Beijnum writes:
On 13-aug-2007, at 17:38, James Carlson wrote:
There's a problem with that idea. There's no guarantee in any
deployment that the DHCPv6 server is actually the definitive source of
information about the prefixes that are on the link. Routers are
supposed
solicitation and a DHCP solicit
message?
I'm not wild about the idea of a single message getting replies from
two separate entities. I suppose it's doable, but it seems like
needless complexity. What is being optimized and why?
--
James Carlson, Solaris Networking [EMAIL PROTECTED
background (for the past 20 years or
so) has been in embedded systems as well.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Iljitsch van Beijnum writes:
On 20-jul-2007, at 2:36, James Carlson wrote:
Still better to have different maximum packet sizes for v4
and v6, though.
That sounds like an IP configuration issue, not a PPP issue.
Isn't that what the NCPs are for, to provide the necessary glue
to think about privacy addresses etc?
It works today on Solaris ... not sure about others.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781
operationally as well. You'd end up
with multiple link-local addresses.
I don't think I agree with pushing this issue down into PPP. We don't
do that for Ethernet, so why would PPP be special?
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive
would be helpful. (I thought that was clear
enough from the existing text, but clearer still likely isn't wrong.)
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757
issues.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
IETF IPv6
and that it should be fixed in
draft-ietf-ipv6-over-ppp-v2.)
I don't think I agree. In fact, I don't think the PPP document really
ought to go out of its way to describe how IPv6 works. That's for the
IPv6 documents to do.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun
.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
IETF IPv6
of just
knowing (somehow) that the peer doesn't have any link-layer address.
Plus, as you point out, unreachability detection falls apart if ND
isn't there. And you don't get to see the weird 'R' bit.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network
other ND messages that
make sense without SLA are perfectly ok and usable.
Sure.
What messages, though, _don't_ make sense without SLLA or TLLA
options? I think all of them are defined to work that way. Am I
missing something?
--
James Carlson, Solaris Networking [EMAIL PROTECTED
changes are required in order to make ND-for-
everything-but-address-resolution mode work?
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442
JINMEI Tatuya / 神明達哉 writes:
At Mon, 9 Jul 2007 16:04:39 -0400,
James Carlson [EMAIL PROTECTED] wrote:
As a result, what I've done in the Solaris implementation is to
'defend' the address once -- by sending out my own advertisement in
reply to the received one -- but setting a flag. If I
JINMEI Tatuya / 神明達哉 writes:
At Tue, 10 Jul 2007 07:43:34 -0400,
James Carlson [EMAIL PROTECTED] wrote:
How should an implementor actually take care here? Are you perhaps
referring to the possibility of endless NA battles between a pair of
misconfigured systems? Or something else?
I
JINMEI Tatuya / 神明達哉 writes:
(Intentionally separating the thread since this is irrelevant to the
main focus of completing 2462bis)
Agreed; and changed the subject line as well.
At Tue, 10 Jul 2007 07:43:34 -0400,
James Carlson [EMAIL PROTECTED] wrote:
On the other hand, I'd point out
Basavaraj Patil writes:
On 3/14/07 11:14 AM, ext James Carlson [EMAIL PROTECTED] wrote:
That issue is the exclusive use of IPv4 or IPv6 on Packet CS. Why
must it be exclusive? The first four bits of the datagram tell you
conclusively whether you're looking at IPv4 or IPv6, so why
Ethernet and VLAN CSes.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
to be sufficient provided that structure copy
isn't an important usage.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
for
reasonable applications.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
(using
#define or redefine_extname or similar) and force the unknown bits
off. That'd produce a different set of breakage, but at least
produces obvious results and doesn't require a different API.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive
value on point-to-point
links, but I don't think that implies that it should now be changed in
an incompatible manner.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757
the use of point-to-point links
(rather than what appears to be broadcast emulation), and reducing
energy costs would seem to require having cached data available on the
single peer node to avoid querying everybody.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun
,
then johnsmith.local must rename himself, right?
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
it is a losing proposition.
--
James Carlson, Solaris Networking [EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
.)
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
IETF IPv6
will confuse and break existing implementations.
An Interface ID is exactly what ND needs on a ppp link.
Disagree. Why does it need _any_ link layer address? Why should it
care?
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox
at
all if the peer doesn't know IPv6 -- there's no way a non-IPv6-capable
IP node can forward IPv6 datagrams, is there?)
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803
Alexandru Petrescu writes:
James Carlson wrote:
Alexandru Petrescu writes:
While the document does talk about stateless address autoconf I
think it should also talk about ND. I think it should mention
whether - or not - it's possible, feasible, has been done or
probable, to run IPv6
editor, Srihari Varada,
has agreed to edit both documents.
Comments, questions, or concerns?
Given the lack of expressed consensus, that sounds like the right
solution to me. The document is good enough without it.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun
and perhaps
fixing the DHCPv6 specification to make switching between the two
modes of operation simpler and more consistent.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA
to foster any sort
of security-by-IP-address mechanism.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
.
Placing it above rule 8 means that prefix routing issues are ignored.
It seems to want to go below rule 8 in priority order. But I guess I
could still go along with that as a compromise.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive
, such as an Ethernet interface.
That's the key point.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
(to me) an important issue, as it distinguishes
more broadly across manually-configured as well as temporary
addresses.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757
. [Ignoring privacy and other related issues.]
Perhaps this gets at what you want anyway, since manually assigned
addresses would presumable have the longest lifetime?
Yes, that's equivalent.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive
both are
similar.
In any event, it's a good thing that the operator behind the question
(Alain Durand) is on the list. I hope he can follow up with specifics
of the deployment problem he faces.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive
it's that lack of foresight that may be part of the underlying
concern here.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
words, the preference order
with this flag set becomes temporary first, then manual, stateful,
and stateless last.)
... or, to simplify, defining a stability_of_address(A) function
that can work here.
--
James Carlson, KISS Network[EMAIL PROTECTED]
Sun Microsystems / 1
56 matches
Mail list logo
