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

From: Tina Tsou <[email-masked]>
Date: Wed, 13 Apr 2011 16:13:15 -0700

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

---

From: Tetsuya Murakami <[email-masked]>
Date: Fri, 15 Apr 2011 15:17:44 -0700

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 <[email-masked]>
> Date: 2011/4/14
> Subject: [Int-area] Some comments for 4rd
> To: [email-masked]
> 
> Hi all,
> 
> “ 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.

> 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.

> 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.
> 
> 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.
> 

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

---

From: <[email-masked]>
Date: Mon, 18 Apr 2011 13:27:53 +0900

Hi Tina

>     “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.

You are right. I will change it in the next version of draft.

Chunfa

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Apr 2011 16:19:59 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Sunday, April 17, 2011 9:28 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Int-area] Some comments for 4rd
> 
> Hi Tina
> >     "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.
> 

I noticed the existing text in
http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#se
ction-5 says the client goes into TIME_WAIT ("It is important to realize
that the TCP design makes it undesirable for clients to re-use ports while
they remain in the TIME-WAIT state (typically 4 minutes after the connection
has concluded).") -- however, that depends on the client doing the active
close.  I see that http://tools.ietf.org/html/rfc6056#section-2.3 discusses
what happens when the server does the active close:  the client doesn't go
into TIME_WAIT.  The recommendation in
draft-ietf-intarea-shared-addressing-issues appears to re-enforce the
suggestion in the last sentence of
http://tools.ietf.org/html/rfc6056#section-2.3, which says:

   A simple but inefficient approach to minimize the rate of collisions
   of instance-ids would be, e.g., in the case of TCP, for both
   endpoints of a TCP connection to keep state about recent connections
   (e.g., have both endpoints end up in the TIME-WAIT state).

perhaps you could cite RFC6056 and reduce the discussion in Section 5?

-d

---

From: Tina Tsou <[email-masked]>
Date: Fri, 15 Apr 2011 15:08:52 -0700

Hi all,
Sorry for making noise.
I'm wondering that perhaps
http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-5.3.2
has already solve the ICMP issues.

Best Regards,
Tina TSOU
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tina Tsou
Sent: Wednesday, April 13, 2011 4:13 PM
To: [email-masked]
Subject: [Int-area] Some comments for 4rd
 
Hi all,

 

 

 

 
Best Regards,
Tina TSOU

---

From: <[email-masked]>
Date: Fri, 22 Apr 2011 11:49:12 +0900

Hi, Dan

Thank you for your comments.
I will cite RFC6056 and try to reduce the discussion in section 5.

Chunfa 

I noticed the existing text in
http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-05#se
ction-5 says the client goes into TIME_WAIT ("It is important to realize that the TCP design makes it undesirable for clients to re-use ports while they remain in the TIME-WAIT state (typically 4 minutes after the connection has concluded).") -- however, that depends on the client doing the active close.  I see that http://tools.ietf.org/html/rfc6056#section-2.3 discusses what happens when the server does the active close:  the client doesn't go into TIME_WAIT.  The recommendation in draft-ietf-intarea-shared-addressing-issues appears to re-enforce the suggestion in the last sentence of http://tools.ietf.org/html/rfc6056#section-2.3, which says: