A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of
the IETF.
Title : Bridge-like Neighbor Discovery Proxies (ND Proxy)
Author(s) : D. Thaler, et al.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of
the IETF.
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et al.
Filename
On Wed, 23 Feb 2005 17:45:48 -0500,
Soliman, Hesham [EMAIL PROTECTED] said:
Hmm...I agree with the realistic view itself, but unless
we prohibit
the use of IPsec, I believe it is overkilling to remove requirements
(using RFC2119 keywords) when it is used.
Is it so harmful to revise the
Hi Jinmei and Christian,
It has been a bit confusing with crossing e-mails and
timezone differences.
I think that there's agreement for clarification.
I think that people agree what needs to be clarified.
I'm not sure if it's decided where to put the clarification
(but I don't care myself, so long
A diff from the previous (-00) draft can be found at:
http://people.nokia.net/~hinden/draft-ietf-ipv6-addr-arch-v4-01.html
and a diff between the current (-01) draft and RFC3515x can be found at:
http://people.nokia.net/~hinden/diff-rfc-draft.html
The latter was made be removing most of the
On Fri, 18 Feb 2005 [EMAIL PROTECTED] wrote:
Title : IP Version 6 Addressing Architecture
Author(s) : R. Hinden, S. Deering
Filename: draft-ietf-ipv6-addr-arch-v4-01.txt
Two high-level comments:
1) The use of compatible addresses does not belong to
Hi Jinmei, Greg, Hesham.
JINMEI Tatuya wrote:
Greg Daley said:
It has been a bit confusing with crossing e-mails and timezone
differences.
Sorry, I actually noticed the possible confusion when I was writing
the messages, but I simply let it go..
Actually, the guy who has been messung things up
please ignore.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Hi Christian,
Christian Vogt wrote:
Hi Hesham,
hope this is not too late.
Not sure but the text may suggest to create NC state even if the RS did
not contain a SLLAO. In this case, it's actually not necessary to
create NC state, especially if the router chooses to respond with a
multicast RA.
On Mon, 21 Feb 2005 20:06:45 +0100,
Christian Vogt [EMAIL PROTECTED] said:
...to this...
[...] If there is no existing Neighbor Cache entry
for the solicitation's sender and a Source Link-Layer Address option
was present in the solicitation, the router creates a new
Hi Jinmei,
JINMEI Tatuya / wrote:
On Mon, 21 Feb 2005 20:06:45 +0100,
Christian Vogt [EMAIL PROTECTED] said:
...to this...
[...] If there is no existing Neighbor Cache entry
for the solicitation's sender and a Source Link-Layer Address option
was present in the solicitation,
Hi Jinmei.
[...] If there is no existing Neighbor Cache entry
for the solicitation's sender and a Source Link-Layer Address option
was present in the solicitation, the router creates a new Neighbor
Cache entry, installs the link-layer address and sets its reachability
state to
Hi,
On Wed, 23 Feb 2005 10:27:02 +1100,
Greg Daley [EMAIL PROTECTED] said:
It has been a bit confusing with crossing e-mails and
timezone differences.
Sorry, I actually noticed the possible confusion when I was writing
the messages, but I simply let it go..
I think that there's agreement
Thanks Claudio for the additional information.
It is of note that this draft is expected to obsolete two RFCs --
RFC 3831 (Transmission of IPv6 Packets over Fibre Channel) as mentioned
below as well as RFC 2625(IP and ARP over Fibre Channel). Note that RFC 2625
is IPv4 specific.
Per the
(B = I'd rather use IPv6 if that's ok with everyone since
(B this doc is only applicable
(B to IPv6.
(B
(B Hmm, I actually don't have a strong preference as long as the result
(B is consistent, but just "IP" seems to be more aligned with the sense
(B of Section 2.1:
(B
(B
15 matches
Mail list logo
