Re: [Int-area] Some comments for 4rd

[Tetsuya Murakami <[e-mail]>]

Hi Tina,

Thank you for your comments.

Please see my comments in line.

On 2011/04/13, at 18:05, Tina Tsou wrote:

> From: Tina Tsou <[e-mail]>
> Date: 2011/4/14
> Subject: [Int-area] Some comments for 4rd
> To: [e-mail]
> 
> Hi all,
> 
> I have some comments for 4rd.
> 
> http://tools.ietf.org/html/draft-despres-intarea-4rd-01
> 
> http://tools.ietf.org/html/draft-sun-intarea-4rd-applicability-01
> 
> 1.       In section 4.3.4 of 4rd draft, Figure 4
> 
> In section 2.5.1 of RFC3513, it says:
> 
> “ For all unicast addresses, except those that start with binary value
> 000, Interface IDs are required to be 64 bits long and to be
> constructed in Modified EUI-64 format.”
> 
> The last 64bits of CE IPv6 address should comply with this
> requirement, if you do not have any specific reasons to set them to 0.

Upon receiving an IPv4 packet via IPv4 interface, BR can retrieve the CE index from both the destination IPv4 address and the destination port number if using shared IPv4 address and then BR can generate the destination IPv6 address from the combination of Domain IPv6 prefix and CE index but BR can not get the interface ID for the receiver. So, we are setting it to 0.

> 2.       In section 4.5.1 and 4.5.2, (d) of 4rd draft
> 
> In this case, the packet comes from the internet to the CE/end user,
> there is no address sharing in this direction, why should the Datagram
> ID be replaced by a locally generated one?

If not using IPv4 shared address, I don't think the datagram ID needs to be replaced by a locally generated one. If using IPv4 shared address, only BR might need to replace the datagram ID by using a locally generated one upon forwarding IPv4 packet via IPv4 interface. So, you are right. The datagram ID does not need to be replaced at CE because there is no shared address among the clients connected to the CE. We will update it in the next version of the draft.

> 3.       ICMP does not work in 4rd
> 
> ICMP packet contains no port information, a user can send a ping
> packet to peer, but when the BR receives the response packet, the BR
> does not know how to construct the CE’s IPv6 address based on just the
> IPv4 address, without the IPv4 port info.
> 
> A possible solution is to put the port information into the
> identification field of an ICMP packet:

Yes. Our implementation supports ICMP echo/reply by using the identification field of ICMP header like the port number. NAT44 changes the identification field by using the assigned port-range at CE. We will add some text for this in the next version of the draft.

> a)       When receiving a ICMP packet from the end user, CE should get
> a number from its IPv4 port range, and put it into the identification
> field of the ICMP packet.
> 
> b)       When receiving a response ICMP message from the internet
> side, BR should derive the CE’s IPv6 address based on the IPv4
> destination address and the identification(port) info.
> 
> c)       If BR does not replace the identification filed of a packet,
> then only a) and b) is sufficient; or BR just replace identification
> of packet when the packet is not ICMP packet;
> 
> if the BR replace identification of all packets, then BR have to
> maintain a mapping table of internal identification VS external
> identification, and when receiving a response ICMP packet from the
> internet side, BR should replace the identification based on the
> mapping table before forwarding it to CE.
> 
> 4.       Unable to communicate to users sharing a same IP address
> 
> Users sharing a same public IPv4 address would not be able to
> communicate directly, because they have the same IP address; the IP
> stack would not send out a packet to the network if it thinks the
> destination is itself, but return the packet to itself, just like you
> send a packet to 127.0.0.1.
> 
> Maybe they can communicate to each other via native IPv6;

If using the normal IPv4 stack supported in many operating system, the direct communication of CEs which share the same IPv4 address can not be done. But I think this depends on the implementation. For example, if not assigning shared IPv4 address to any interface and using this shared IPv4 interface in NAT44 as the replaced IPv4 address, the direct communication can be done even though multiple CEs share the same IPv4 address (see "[Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)" mail thread). Also, I think there are any other implementation for achieving the direct communication between CEs which share the same IPv4 address.

Thanks,
Tetsuya Murakami