Messages | Bytes| Who
+--++--+
19.05% | 12 | 18.56% |69973 | [EMAIL PROTECTED]
9.52% |6 | 12.15% |45796 | [EMAIL PROTECTED]
12.70% |8 | 8.69% |32772 | [EMAIL PROTECTED]
11.11% |7 | 8.16% |307
Folks,
Just to make sure this issue is addressed, I think we can allow
routers to either respond with a unicast or multicast RA in the
case where an RS without SLLAO is received. It seems like there
are different cases where multicast would make more
sense than unicast (or at least implementers
> Greg Daley wrote:
> > Putting things in STALE doesn't work unless there's a link-layer
> > address known ( and there's none in the received RS).
>
> Greg is correct. When a node has a packet for a neighbor
> for which the
> NC entry is STALE, it does send the packet (trial and
> er
On Fri, Feb 18, 2005 at 12:15:08PM +0530, Swaroop George A. wrote:
> I would like to know whether following updates are stable enough to
> implement or is there any possibility of having a newer revision on these
> (other than a new RFC)
>
> draft-ietf-ipv6-rfc2011-update-10.txt
> draft-ietf-i
I am just re-joining the list after a several-month hiatus due
to personal circumstances.
Just glancing at the archives over the past few weeks, on the
subject of IPv6 addresses with embedded IPv4 addresses, the
discussion that has taken place so far is incomplete in that
it fails to mention ISATA
Hi Hesham, Greg.
Soliman, Hesham wrote:
Christian, Thanks for the detailed description. I think Nick
brought this up some time ago too. My suggestion is that upon
reception of an RS with no SLLAO the router checks if an entry
already exists, if none exists then it creates one and puts it in
STALE.
Erik,
FWIW it also support a single proxy having multiple downstream interfaces.
I don't know if that is an interesting case when multiple L2 technologies
are being used.
Good point. I can think of a device with more than two interfaces (for
example, GPRS, WLAN, BT, and USB).
I think people ar
Hi,
I would like to know whether following updates are stable enough to
implement or is there any possibility of having a newer revision on these
(other than a new RFC)
draft-ietf-ipv6-rfc2011-update-10.txt
draft-ietf-ipv6-rfc2012-update-06.txt
draft-ietf-ipv6-rfc2013-update-04.txt
thanks
Swaroo
Hi,
Just FYI.
IPv6 Promotion Council of Japan has developed the web-based
IPv6 space management tool and make the source code
available to public. This tool is especially prepared
for LIRs to report the assignments of /48s to RIRs which
is mandated by RIR's IPv6 allocation and assignment policy.
ht
> On Sat, 19 Feb 2005, Markku Savela wrote:
> > This would work just fine, if nodes on internal network take the RA
> > prefix length as is, and just trunctate their ID-parts from higher
> > ends (or they could just generate ID randomly). Throw away all this
> > sillyness with fixed 64-bit ID etc.
Hi Hesham,
- Original Message -
From: "Soliman, Hesham" <[EMAIL PROTECTED]>
Date: Saturday, February 19, 2005 2:21 pm
Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
> Hi Greg,
>
> I was definitely assuming that address resolution will
> take place in the case where the resp
On Sat, 19 Feb 2005, Markku Savela wrote:
This would work just fine, if nodes on internal network take the RA
prefix length as is, and just trunctate their ID-parts from higher
ends (or they could just generate ID randomly). Throw away all this
sillyness with fixed 64-bit ID etc..
This would requir
12 matches
Mail list logo
