function 'tuple5()' in 'compute_out_tuple' should't use 'pool6_peek' to get prefix #106

Closed
airsnail opened this Issue Sep 2, 2014 · 4 comments

Projects

None yet

2 participants

@airsnail
airsnail commented Sep 2, 2014

Function 'tuple5()' in 'compute_out_tuple' should't use 'pool6_peek' to get prefix when there is serval prefix in pool6.When turn packet form ipv6 to ipv4, we take out prefix from ipv6 address.Then the reply ipv4 packet arrives, we should get right prefix to trun packet back. 'pool6_peek' can't get prefix correctly when there is serval prefix in pool6. We should get prefix from session.

@ydahhrk
Member
ydahhrk commented Sep 3, 2014

Correct. Adding to new milestone; thank you.

It seems to me that the change should also be applied to tuple3().

@ydahhrk ydahhrk added this to the 3.2.1 milestone Sep 3, 2014
@ydahhrk ydahhrk self-assigned this Sep 12, 2014
@ydahhrk ydahhrk added a commit that referenced this issue Sep 18, 2014
@ydahhrk ydahhrk Issue #106.
Not tested. It also propts to simplify the code further.
b93fb1c
@ydahhrk
Member
ydahhrk commented Oct 8, 2014

This overcame testing already.
Sorry for asking so late, but would you like credits in Jool's README?

@ydahhrk ydahhrk added a commit that referenced this issue Oct 8, 2014
@ydahhrk ydahhrk Merging version 3.2.1 into master, hereby makingthe changes official.
Version 3.2.1 is 3.2.0 with issues #57, #106, #108 and #109 fixed.
Issue #107 has been marked as duplicate and postponed to 3.3.0.

rting with '#' will be ignored, and an empty message aborts
3025ec2
@airsnail
airsnail commented Oct 9, 2014

Oh,yeah,my pleasure! It's great!

------------------ 原始邮件 ------------------
发件人: "ydahhrk";notifications@github.com;
发送时间: 2014年10月9日(星期四) 凌晨0:35
收件人: "NICMx/NAT64"NAT64@noreply.github.com;
抄送: "Snail"642773391@qq.com;
主题: Re: [NAT64] function 'tuple5()' in 'compute_out_tuple' should't use'pool6_peek' to get prefix (#106)

This overcame testing already.
Sorry for asking so late, but would you like credits in Jool's README?


Reply to this email directly or view it on GitHub.

@ydahhrk
Member
ydahhrk commented Oct 10, 2014

Done.

@ydahhrk ydahhrk closed this Oct 10, 2014
@ydahhrk ydahhrk added a commit that referenced this issue Mar 11, 2015
@ydahhrk ydahhrk Fixes #132.
I messed up Compute Ougoing Tuple when I tried to fix #106.
I assumed the session always contained the information the tuple needed. In reality, in 4 -> 6 the session contains the address the packet was originally intended to, which is not necessarily the node which answered the request.
While COT is now in line with RFC 6146 again, and this code addresses #106 and #132 at the same time, it seems to me some errata is in order because now the destination address of the inner packet (of the ICMP error) is wrong.
b00dcf4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment