Hi,
Exactly. In IPv4 the "tethering" can be done with NAT & DHCPv4 server in UE,
but in IPv6 ND Proxy is needed until UEs can get more prefixes from 3GPP
network with prefix delegation techniques (such as DHCPv6 PD).
Best regards,
Teemu
--- original message ---
From: "ext Laganier, Julien"
S
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) ?
Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in parall
Ah, OK. If I get time, I will review the document in next week or two.
Thanks,
Hemant
-Original Message-
From: Laganier, Julien [mailto:juli...@qualcomm.com]
Sent: Wednesday, November 18, 2009 12:56 PM
To: Hemant Singh (shemant); Pekka Savola
Cc: ipv6@ietf.org; draft-ietf-csi-proxy-s...
Brian E Carpenter allegedly wrote on 11/10/2009 9:54 AM:
> Fred,
>
> Another approach to problem 3 is to extract REAP from SHIM6 and
> figure out how to use it to enhance address selection in practice.
... or any mechanism which tests src/dst address pairs. Note that
data packets and control pac
Hemant,
Right - I understand that some deployments do not require SEND security.
As a side note, draft-ietf-csi-proxy-send-01 has just entered WGLC in the CSI
WG, reviews by interested parties would be appreciated!
Thank you.
--julien
> -Original Message-
> From: Hemant Singh (shem
Julien,
Thanks - we will update our draft to change the info that now the CSI
group is working on SEND extensions for ND Proxy and it's Work in
Progress. However, one original intent of our draft is still valid that
some deployments want to use ND Proxy but will not use SEND.
Hemant
-Origin
On Nov 18, 2009, at 7:43 PM, Arifumi Matsumoto wrote:
As I wrote in another e-mail, rather than giving over everything to
hosts, I think, giving hints for selecting addresses should be
reasonable, at least in some environments.
I would very much favor having an icmp message that the networ
On Wed, 18 Nov 2009, Arifumi Matsumoto wrote:
Regarding this way of try-and-error approach,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some
Fred,
On 2009/11/18, at 18:50, Fred Baker wrote:
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently
out-thinks the network design?
IMO, we ca
On 2009/11/18, at 18:46, Fred Baker wrote:
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them cl
Regarding this way of try-and-error approach,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destinatio
On Nov 18, 2009, at 6:43 PM, Arifumi Matsumoto wrote:
I'm not sure we can create perfect-in-every-environment
caching algorithm.
but you're convinced you can design an algorithm that consistently out-
thinks the network design?
wow. I'm not that optimistic.
On Nov 18, 2009, at 6:22 PM, Arifumi Matsumoto wrote:
I guess that is because if you force to try all the pairs, it
perfectly
ignores the address selection manner defined in RFC 3484, and thus,
it gives us not little impact.
If they space them closely and run them in parallel, I guess I don
Mohacsi,
I think It should be implemented the following way:
for each source address in some order {
create socket
bind (current source address)
for each destination address in some order {
connect (current destination address)
do {
Fred,
On 2009/11/11, at 7:52, Fred Baker wrote:
On Nov 11, 2009, at 2:00 AM, Mohacsi Janos wrote:
I think this try_and_success_or_failure method can work in most
cases, however it has some burden for implementation and
operational point of view,
It does indeed, at least operationally. T
16 matches
Mail list logo
