Hi Murakami,
Thank you for your reply. Please see my comments in lines.
From: Tetsuya Murakami
Date: 2012-03-01 10:14
To: sunqi.csnet.thu
CC: Tetsuya Murakami; softwires WG
Subject: Re: Comments on MAP-E draft
Hi Qi,
Thank you for your comments. Please see my comments in line.
On 2012/02/29, at 1:18, Qi Sun wrote:
Hi Murakami,
It's a good draft and makes a nice support for the MAP mechanism. I would
like to propose some comments on the draft(sorry if they've been discussed
ever). Please check below.
-----------------------------------------------------------------
Section 5.2 Packet Forwarding Behavior on MAP-E BR
Part (b) BR reception of an IPv6 packet
BR derives a CE IPv6 address from
the IPv4 source address or the IPv4 source
address and the source port in the encapsulated
IPv4 packet based on the BMR. If the CE IPv6
address is eqaul to the IPv6 source address in
the received IPv6 packet, BR decapsulates the
IPv4 packet and then forward it via the IPv4
interface.
I have a few questions here.
1. How can the BR get from an IPv6 packet the IPv4 source address or the IPv4
source address and the source port in the encapsulated IPv4 packet?
In case of MAP-E, IPv4 packet is encapsulated in IPv6. The above text is for
check the validation of the received packet. In terms of IPv6 packet received
at BR, the IPv6 source address should be based on the IPv6 prefix delegated to
CE. Also, according to the MAP rule, IPv4 address and port number can be
derived from the same delegated IPv6 prefix. So, BR can calculate CE IPv6
address from the IPv4 source address and source port number in IPv4 packet
encapsulated in the received IPv6 packet. If the calculation is failed, then
the packet could be dropped. If the calculation is succeeded but the calculated
CE IPv6 address is not matched to the source IPv6 address in the received IPv6
packet, then the packet could be dropped.
[Qi Sun] I have 2 questions here.
[Qi Sun] 1.My understanding is that the BR get the IPv4 related info from the
IPv6 packet by reading the specific bits in the IPv6 packet, that is the IPv4
address is put in the exact position in the IPv6 packet. Right?
[Qi Sun] 2.You said,'If the calculation is failed, then the packet could be
dropped.' I think this action may cause the data loss of normal IPv6 flow.
2. If the received IPv6 packet is a normal one, instead of an IPv4-encapsulated
packet, what will the BR do? That is, dose the BR can act as a normal router?
In this case, BR should handle this IPv6 packet based on the normal IPv6
routing because the next header is not IPv4 in this case.
[Qi Sun] Agree :)
3. What can cause the inequality between the derived CE IPv6 address and the
IPv6 source address in the received IPv6 packet? And what will BR do with it,
discard it ?
It might depend on the implementation. But the derived CE IPv6 address must be
same as the IPv6 source address in case of MAP-E because the derived CE IPv6
address should be the tunnel end-point address on the CE. So, the received
packet should be discarded or not processed as MAP-E packet.
[Qi Sun] You mean, in the MAP-E case, the inequality won't happen, right?
My question is that whether the MAP-E nodes can be deployed with the normal
IPv6 nodes. If can't, won't it cost too much to deploy brand new MAP-E domains
for SP? If can, is it possible to be stated in the draft, with the
considerations of BR handling non-MAP-E IPv6 packets ?
Looking forward to ur reply~
[Qi Sun]
Best Regards,
Qi Sun
-------------------------------------------------------------------
Thanks,
Tetsuya Murakami
I'm looking forward to your reply~
Best Regards,
Qi Sun
Tsinghua University, Beijing, China_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
