OK, so the action I take is that I think there should be some text added
to explain this case. When I get to making the next revision, I'll send
you the text to make sure this is covered.
Thanks,
Gorry
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
Gorry Fairhurst wrote:
Hi,
is RFC 5014 what you are looking for ?
On 2009/06/29, at 20:40, Aleksi Suhonen wrote:
Hi,
Address selection happens in many places: in some cases it's
supposed to happen inside the kernel, in some cases inside a library
and in some cases in the application.
Would it make sense to cr
Gorry Fairhurst wrote:
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (wh
Stig Venaas wrote:
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are de
Gorry Fairhurst wrote:
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are determined). I guess
t
Stig Venaas wrote:
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are determined). I guess
the main case where this
I think this is a good idea, just some minor comments.
The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are determined). I guess
the main case where this isn't the case, is w
Primarily because it still required work on SEND extensions before the
security story was complete. The CSI WG was then chartered to do that
work (among other things).
-Dave
From: Hemant Singh (shemant) [mailto:shem...@cisco.com]
Sent: Monday, June 29, 2009 6:20 AM
To: ipv6@ietf.org
Cc: Dave Tha
6man folks,
Does anyone know why RFC 4389 was deemed as Experimental for status as
opposed to say, Standards Track?
Thanks,
Hemant
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://w
Hi,
Address selection happens in many places: in some cases it's supposed to
happen inside the kernel, in some cases inside a library and in some
cases in the application.
Would it make sense to create a uniform API so that no matter where it
takes place, it has access to all the same input
I've submitted a revision of the I-D below, and would be keen to see
some discussion on this list as to whether this could solve the
perceived problem that some tunnel protocols do not wish to employ the
UDP checksum as specified in RFC 2460.
I would like to present this short draft in Stockho
Brian E Carpenter wrote:
This creates a black hole not only for Site A, but also any other sites
in the Internet, if ULA is visible in DNS.
So, preventing a black hole only for ULA site does not suffice.
True. Which shows that our scope model is too simple for the real world.
While writing m
Hemant Singh (shemant) wrote:
An RS with a unicast destination is legal as per RFC 4861. For example,
first time when a host was initialized, the host sent an RS with mcast
destination. Then the host received an RA and the host acquired IPv6
address(es) and is up and running. After a while the
13 matches
Mail list logo
