Subject: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)

From: Dmitry Anipko <[email-masked]>
Date: Mon, 11 Apr 2011 17:11:29 -0700

Hi,

Since re-chartering to include 4rd has not been approved yet (as far as I know), I'm not sure if softwires is the right forum for this question, please let me know if intarea is a better one for the time being.

Draft-despres-intarea-4rd-01 allows for configuration of end hosts (since it defines CE as "a host, a router or both") with shared addresses with restricted port sets. My understanding is that usage by applications of such addresses, assigned to interfaces, may have issues - for example, those are discussed in http://tools.ietf.org/html/draft-dec-stateless-4v6-00 . 

Should the draft include a recommendation to either avoid assigning such addresses to interfaces, and use it only in the NAT function, even when CE is a host, or, as draft-dec-stateless-4v6-00 suggests in section 3.1.2, modify the 4rd DHCP option to provide for CE ability to specify whether it is capable to function with a shared address? (since 4rd can also distribute not shared addresses / address ranges)

Thank you,
Dmitry

---

From: Mark Townsley <[email-masked]>
Date: Tue, 12 Apr 2011 22:03:58 +0200

Hello Dmitry,

My view is that 4rd is most easily understood if and only if it connects to a CE function that is performing NAPT. The CE function may be in what is traditionally considered a host, or in what is clearly a router.

More specifically, a device that is forwarding packets from one interface (virtual or otherwise) to another through a NAPT that has one interface with IPv6 configured (via DHCPv6 or otherwise) as performing 4rd (which enables dual-stack via a port-restricted IPv4 address for the NAPT using IPv6 as the transport) then you a have a 4rd CE. That could be a "host" in that it is a Windows PC with internet connection sharing for IPv4 turned on and hence forwards packets between interfaces with a NAPT due to the IPv4-enabled interface created when 4rd is configured. 

I would avoid anything that requires the host forwarding table to be altered to accommodate 4rd. Instead, the NAPT function that is already present in a small router or host configured to look like a router is modified to use a set of ports that it is allowed to use when 4rd is enabled. 

- Mark

On Apr 12, 2011, at 2:11 AM, Dmitry Anipko wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 13 Apr 2011 14:23:30 -0700

Hello Mark,

I agree that if the 4rd IPv4 address is only used in such a way, that applications cannot start use the address directly (such as e.g. perform binding to the address assigned to an interface), then this issue doesn't apply.

However I'm not sure that the current draft makes clear that this is the only intended use. For example, it defines CE as "a node.. it may be a host..", instead of saying that CE is a function implemented in a host. Also, the introduction in section 1 also does not include NAPT as a required element of the solution (it says "The 4rd mechanism tunnels IPv4 over IPv6 using an algorithmic mapping.."). 

Some existing implementations may be assigning the address used for NAPT to an interface (and as long as the address is for the host exclusive use, an implementation is able ensure such usage doesn't cause problems) - that's what Windows ICS you mentioned actually does.

With the current language, I don't think it is unlikely that implementers will be tempted to assign a 4rd IPv4 address to an interface (e.g. with intent to enable wider set of apps to work without a NAPT in the middle), and if the spirit of the draft is that the IPv4 address assigned to the node by 4rd should be only be used for CE function, performing NAPT, (or more specifically, should not be made available for applications to bind) then I think it may be useful to state it as such to guide implementers.

Thank you,
Dmitry

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 1:04 PM
To: Dmitry Anipko
Cc: [email-masked]
Subject: Re: [Softwires] sharing restricted addresses by hosts in 4rd (draft-despres-intarea-4rd-01)

Hello Dmitry,

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 14 Apr 2011 02:06:14 +0200

> With the current language, I don't think it is unlikely that implementers will be tempted to assign a 4rd IPv4 address to an interface (e.g. with intent to enable wider set of apps to work without…

Then at least you and I agree. If 4rd becomes a WG item, this is the kind of change we should be able to affect in the draft with WG consensus. 

- Mark

---

From: Alain Durand <[email-masked]>
Date: Tue, 19 Apr 2011 09:06:04 -0700

> I would avoid anything that requires the host forwarding table to be altered to accommodate 4rd. Instead, the NAPT function that is already present in a small router or host configured to look like…

Mark:

How would an app running on a 4rd CPE communicate in IPv4 to another app running on another 4rd CPE?

   - Alain.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 Apr 2011 18:17:01 +0000

> How would an app running on a 4rd CPE communicate in IPv4 to another app running on another 4rd CPE?

First, by definition any 4rd CPE has IPv6. So, if your application works with IPv6. 4rd-to-4rd is as easy as knowing two IPv6 addresses and not having a simple-minded firewall between the two blocking traffic.

For IPv4, in the model I describe above, all applications are sitting behind the NAPT within the CPE bound to the 4rd tunnel. End-to-end looks just about as desperate and ugly as it does today between any series of NAPTs and firewalls. Skype will make its way through, I suspect with no modifications. 

- Mark

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 20 Apr 2011 19:13:44 +0000

I agree that any p2p application using relay would work on 4rd.

For two 4rds using the same v4 address but different port-ranges, I guess
the two 4rd devices would communicate directly w/o BR (Section 4.5.1)
because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds using
the same 4rd prefix.

/Yiu

On 4/20/11 2:17 PM, "Mark Townsley" <[email-masked]> wrote:

>For IPv4, in the model I describe above, all applications are sitting
>behind the NAPT within the CPE bound to the 4rd tunnel. End-to-end looks
>just about as desperate and ugly as it does today between any series of
>NAPTs and firewalls. Skype will make its way through, I suspect with no
>modifications.

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 20 Apr 2011 16:21:30 -0700

Alain,

> How would an app running on a 4rd CPE communicate in IPv4 to another app running on another 4rd CPE?

IPv4 address generated from assigned IPv6 address can be used in only 4rd CPE function. For example, this IPv4 address is used by only NAT44. So, the application running on 4rd CPE box does not use this IPv4 address generated from IPv6 address.

If the application supports IPv6, the application can use the assigned IPv6 address because each 4rd CPE has a unique IPv6 address. Also, if a private IPv4 address is assigned to IPv4 interface on 4rd CPE box, the application can use this private IPv4 address.

Thanks,
Tetsuya Murakami

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 21 Apr 2011 14:14:15 +0900

Hi Alain, Tetsuya,

Just one supplement.
4rd "CPE" is equipment, which have 4rd "CE" function.

Best regards,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 21 Apr 2011 14:17:37 +0900

Hi Yiu,

> because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds using

Correct, thanks.

--satoru

---

From: Alain Durand <[email-masked]>
Date: Fri, 22 Apr 2011 10:20:12 -0700

>> because 4rd CPE has mesh connectivity (over IPv6) to all other 4rds using

How would you accomplish that in IPv4 without changing the IPv4 forwarding rules?

  - Alain.

---

From: Tetsuya Murakami <[email-masked]>
Date: Fri, 22 Apr 2011 14:47:39 -0700

Hi Alain,

> How would you accomplish that in IPv4 without changing the IPv4 forwarding rules?

As I mentioned before, the shared IPv4 address is used for only 4rd CE function which is implemented in 4rd CPE box. This shared IPv4 address can be used in only NAT44. For this, this shared IPv4 address does not need to be assigned to any physical interfaces on 4rd CPE box. Any applications running behind 4rd CPE box use a private IPv4 address and then 4rd CE function in 4rd CPE box does NAT44 for the packets generated by these applications. After that, all communications can be done by using IPv6 between 4rd CPE boxes. So, I don't think IPv4 forwarding rules does not need to be changed.

Thanks,
Tetsuya Murakami