Hi,
I am running IPV6CP for PPP links. I will come to know the link local
address from IPV6CP itself. I can also derive (global eui-64 based) global
unicast address based on IPV6CP identifier.
My doubt is Should I run ND on PPP links in addition? Can any one please
tell me with the reason?
From router point of view, global address can be get from
Configuration. So
I am still thinking, for router case do we need ND?
= Do you think hosts connected to your router
will need the information I mentioned in the last
email? If yes, they will send RSs.
I don't know what you're
On 14-apr-04, at 12:48, Ralph Droms wrote:
I think DHCPv6 ought to be cited as the protocol for other
configuration
information, as well.
However, it seems to me the phrase stateful protocol for *other*
configurations is a little misleading. I think the word stateful
could
be dropped.
And
I suggest dropping stateful from the description because of the potential
for confusion inherent in providing a stateful protocol for *other*
configurations with stateless DHCPv6 [RFC 3736].
This confusion arises from the unfortunate decision to differentiate
RFC 2462 address assignment from
On Apr 14, 2004, at 3:48 AM, Ralph Droms wrote:
Jinmei-san,
I think DHCPv6 ought to be cited as the protocol for other
configuration
information, as well.
This is the logical extension.
However, it seems to me the phrase stateful protocol for *other*
configurations is a little misleading. I
In any event, perhaps the best way to simplify the protocol would be
to
drop
the O bit altogether. That is, make no attempt to control how a
host
goes
about finding the additional configuration information. There was a
brief
discussion about this issue at an IPv6 WG interim meeting (Aug
Followup on the meaning of stateless - one way to interpret stateless in
the context of DHCPv6 is: does not require the maintenance of any dynamic
state for individual clients (RFC 3736). The server does, of course,
maintain configuration state and can make decisions about the response sent
to
Hi Ralph,
I suggest dropping stateful from the description because
of the potential
for confusion inherent in providing a stateful protocol for *other*
configurations with stateless DHCPv6 [RFC 3736].
= I don't find the words stateful and stateless confusing
at all in this context. I
On Apr 14, 2004, at 10:11 AM, Ralph Droms wrote:
Followup on the meaning of stateless - one way to interpret
stateless in
the context of DHCPv6 is: does not require the maintenance of any
dynamic
state for individual clients (RFC 3736). The server does, of course,
maintain configuration state
On 14-apr-04, at 14:35, Ralph Droms wrote:
I suggest dropping stateful from the description because of the
potential
for confusion inherent in providing a stateful protocol for *other*
configurations with stateless DHCPv6 [RFC 3736].
This confusion arises from the unfortunate decision to
Ralph Droms wrote:
Autonomous/managed or serverless/server-based might be more
correct...
If asked to vote on one of these two proposals, I would select
autonomous/managed; a node that is autonomous in terms
of address configuration might be a server for some other
function unrealted to
That is not a 3rd party scenario. The network manager is serving 2 sets of
customers. Therefore the network manager is required to keep the services to
those independent customer sets straight. If the 'outsider' (party 1) gets
back unusable addresses it is the network manager's (party 2) problem.
12 matches
Mail list logo
