[Int-area] Some comments for 4rd

[Tina Tsou <[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.
 
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?
 
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:
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; 
 
5.       In section 5 of applicability draft
"Shared address issues [I-D.ietf-intarea-shared-addressing-issues] describes
a method for
   the random selection of TCP Sequence Number, that reduces the ability of
attacker to correctly guess the 5-ruple."
 
   Random selection of TCP Sequence Number is to prevent the attacker from
guessing the next TCP SN, not the 5-tuple.
 
 
 
We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html