Fernando Gont wrote:
Hi, folks,
It has been pointed out to me of the IPRs on SEND/CGAs, which I checked
at:
*
https://datatracker.ietf.org/ipr/search/?option=rfc_searchrfc_search=3
971
*
https://datatracker.ietf.org/ipr/search/?option=rfc_searchrfc_search=3
972
KAME also
Hi Suresh,
Suresh Krishnan wrote:
Hi Julien,
On 10-09-08 07:43 PM, Laganier, Julien wrote:
Thomas Narten wrote:
[...]
RAs/SLAAC work very well when RAs can be multicast to *all* nodes on
a link, and *all* nodes receive exactly the same information about
prefixes and SLAAC. I.e
Hi Suresh,
Please see two comments below:
Suresh Krishnan wrote:
Hi Shree,
Thanks for the comments. Please find responses inline.
On 10-09-07 09:38 AM, JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK) wrote:
Suresh,
One of the main challenge in implementing the model proposed by the
Thomas Narten wrote:
[...]
Joel M. Halpern j...@joelhalpern.com writes:
[...]
Now, operators wanted to offer IPv6 service. I hope we think that is a
good thing. For residential, they looked at what they could count on
from the hosts. And some of them concluded that they could
Hi Suresh,
Suresh Krishnan wrote:
Hi Ralph,
Snipped a whole lot of old quoting
On 10-08-26 08:18 PM, Ralph Droms wrote:
Suresh...
But the multicast RAs don't advertise prefixes, right, so the
subscriber nodes won't be able to complete SLAAC?
Correct.
I think the point is
Manfredi, Albert E wrote:
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Thus, it is my recommendation that the next version of the node
requirements document make support for IPsec and IKE both SHOULDs
only, with a lot more explanatory text
Thomas,
Please see some comments below:
Thomas Narten wrote:
Folks,
A revised version of draft-ietf-6man-node-req-bis-05.txt has been
published, but it's Security section needs work. In particular, the WG
needs to answer the following questions:
- Should IPsec be a SHOULD or MUST?
Hello Teemu,
A question for clarification about the 3GPP use-case you have in mind. Are you
thinking about a 3GPP User Equipment being allocated a /64 prefix on the 3GPP
link and acting as an ND proxy between the 3GPP link and downstream links to
which other nodes could attach (e.g. a laptop)
Hemant,
The CSI WG has been chartered in 2008 to develop an ND proxy support for SEND
and has a corresponding work item:
http://tools.ietf.org/html/draft-ietf-csi-proxy-send-01
--julien
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Just for the sake of getting the discussion started, I drafted some text
we can discuss:
Secure Neighbor Discovery [RFC3971] SHOULD be supported. [RFC4861] states:
Cryptographic security mechanisms for Neighbor Discovery are outside
the scope of this document and are defined in
) but
it's not always possible to know.
I agree with the SHOULDs and the intention of the MAY, I just don't
know if a host knows enough to decide about the MAY.
Hesham
On 23/07/09 12:59 PM, Laganier, Julien juli...@qualcomm.com wrote:
Just for the sake of getting the discussion started, I
9:03 PM
To: hes...@elevatemobile.com; Laganier, Julien; nar...@us.ibm.com;
ipv6@ietf.org
Subject: RE: Node Requirements: Issue 13 - CGA/SeND support
Hesham,
I agree with you, the Node cannot know this, it can only do the right
thing once the SeND process starts. Do people feel that SeND
12 matches
Mail list logo
