> Ideas something like this have been proposed several times. I don't
> remember the conclusion of the discussion on each one of them, but, in
> any event, this is clearly beyond the scope of rfc2462bis.
OK,
Another suggestion.
Instead of turning off loop-back supression of WLAN,
Another solutio
On page 25 of
2662bis 07 draft the difficulties for loopback and dad
are
explainded.
Maybe dedection of
loopbacks (of NS) could be supported by adding
a new option either
as NS option or as destination header option.
This option should
carry a random identifier of sufficient len
In 4. Healing of Network Partitions
states:
Hosts on disjoint network links may configure the same IPv4 Link-
Local address. If these separate network links are later joined or
bridged together, then there may be two hosts which are now on the
same link, trying to use the same address.
To my mind
On page 59, 7.2.5 is written:
->
If the Neighbor Cache entry is not in INCOMPLETE state, the receiving
node performs the following steps:
- It records the link-layer address in the Neighbor Cache entry.
- If the advertisement's Solicited flag is set, the state of the
entry is set
Hi, sorry for bothering.
I would like to know how MLDv2 can currently work
Without being temporarily being forced to MLDv1 mode,
Even if all listeners have MLDv2 implemented.
RFC2461 (even the newest draft
)
Requires on page 56, chapter 7.2.1 interface initialization -
To use MLD [MLD] for joi
Hi,
I have a question regarding 6.3.4 in the above
neigbour-discovery draft.
On page 49 it is stated, that if reachable time is
not updated by new router advertisements, a host
SHOULD recompute a new random reachable time value every few hours.
Can anybody tell me why a host should do this ?
- wha
Ipv4 compatible addresses also entered RFC3484
-default address selection. In this RFC a special label (3)
Is defined for them.
Will that text also be updated ?
Best regards
Peter
IETF IPv6 working group mailing list
ipv6@ie
, 3.3 -> 1) .. When adjusting the lifetime of
an existing temporary address, only lower the lifetime.)
Best regards
Peter
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Freitag, 15. Oktober 2004 14:33
To: Grubmair Peter
Cc: 'Pekka Savola'; IPV6
I want to state that I personally do not like the new
idea from the draft to consider total lifetimes of a
temporary address in case of some RAs renew prefixes.
(Previously lifetimes of temporary addresses could only be
lowered by RAs).
This adds additional complexity for the rather rare
event of a
In the state diagram in RFC2461-bis
in Appendic C, page 79, the event of receiving
a NA with solicitated = 1 and Override = 0
in state DELAY is not handled.
To my understanding the same treatment as in
state STALE or PROBE has to be applied.
To me it also seems, that the state DELAY can
be treate
I support
2. M=1 => Solicit/Advertise/Request/Reply is available
O=1 => Information-request/Reply is available
and hope that the flags will remain independent from each other.
Best regards
Peter
IETF IPv6 working group
For Duplicate address dedection RFC2462,
a node must join the solicitated-node-multicast
address before Duplicate Address dedection.
For verifying link-local address, this will mean, that
only a tentative link-local address is available.
I would like to know, which source address shall
be used in M
In RFC3484 source address selection is described,
which selects a source address from a candidate
set by defining a total ordering onto the addresses.
Typically (RCOMMENDED) the candidate set consist of just the addresses
assigned to the outgoing interface.
In case that all global addresses assigne
In page 49, chapter 4.3.4 of draft-soliman-ipv6-2461-bis-01.txt
it is stated that after reception of Router Advertisement, which
contains a source link-layer address option, a new
neighbor cache entry SHOULD be created.
The state of this new cache entry shall be STALE.
But to my mind, if the desti
Dear Sirs,
I highly appreciated finding your draft
concerning "DHCP Option for Configuring IPv6-over-IPv4 Tunnels"
at IETF.
To my mind this is one of the simplest form of a first transition
for mobile (GPRS) operators to supply IPv6 to
their customers.
After finding the tunnel endpoint via y
I wonder how an IPv6 RAC-node gets to know
any router, if it is connected in an IPv6/Ipsec/Ikev2
VPN scenario.
IKEv2 configuration payload only assigns an address+ netmask
and gives DHCPv6 server address, but DHCPv6 does not
have any options for publishing routers.
Therefore to get to know routers
16 matches
Mail list logo
