Subject: [Softwires] The Framing discussion of yesterday

From: Rémi Després <[email-masked]>
Date: Thu, 28 Jul 2011 17:58:56 +0200

Hi, Dave,

1.
I completely agree with the need you expressed to clarify what is meant by stateless depending on which states it applies to.

2.
Unless I misinterpreted, you asked about the failure mode of a host that isn't part of a shared IPv4 address system and is attached to such a system. 

Assuming that, in the context of the discussion, this implicitly referred to a "static" shared-address system, I don't see which problem there would be:
- If a node is attached to an IPv6 network and ignores the static shared-address system of this network, it won't be able to receive/accept parameters of this-system mapping rule(s). 
- It will therefore ignore that it could have used an exclusive port set of a global IPv4 address. 
- It will do nothing with its assigned address-and-port-set.  

Is this OK, or did you have in mind something more complicated which you could detail?

Kind regards,
RD

---

From: Qiong <[email-masked]>
Date: Fri, 29 Jul 2011 13:19:30 +0800

Hi, Remi, Dave,

I'm not sure whether I get the point in Dave'd slide. Please correct me if
anything is wrong.

In my understanding, the major problem in this failure mode would happen on
the downstream path, rather than the upstream one.  A node which is attached
to an IPv6 network can determine whether to use shared-address system or
not. However, when the downstream IPv4 packet arrived at the network-side
GW, it can not tell whether the packet should be translated into shared-mode
or exclusive-mode. So it can not work unless network-side GW have know these
IPv4 addresses in advance for either mode.

Moreover, I think this issue would have distinct impact on stateless
solutions and stateful ones. For stateful ones, the states in AFTR have
already shown the binding information between IPv4 address/port set and IPv6
address explicitly. While for stateless ones, these address mapping rules
are determined implicitly in algorithm. As a result, in order to reflect
prefix mapping information (discussed in multiple prefix threads), some more
rules would be needed to be introduced accordingly . Of course, the number
of rules would be significantly less than the number of states .

Best regards

Qiong Sun

> 2.
> Unless I misinterpreted, you asked about the failure mode of a host that
> isn't part of a shared IPv4 address system and is attached to such a system.
>
> Assuming that, in the context of the discussion, this implicitly referred
> to a "static" shared-address system, I don't see which problem there would
> be:
> - If a node is attached to an IPv6 network and ignores the static
> shared-address system of this network, it won't be able to receive/accept
> parameters of this-system mapping rule(s).
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 09:42:44 +0200

Le 29 juil. 2011 à 07:19, Qiong a écrit :

> Hi, Remi, Dave,
> 
> I'm not sure whether I get the point in Dave'd slide. Please correct me if anything is wrong.
> 
> In my understanding, the major problem in this failure mode would happen on the downstream path, rather than the upstream one.  A node which is attached to an IPv6 network can determine whether to use shared-address system or not. However, when the downstream IPv4 packet arrived at the network-side GW, it can not tell whether the packet should be translated into shared-mode or exclusive-mode. So it can not work unless network-side GW have know these IPv4 addresses in advance for either mode. 

In the downstream direction from the Internet, the stateless BR (no per customer state) maps the destination transport-address to an IPv6 destination address.
Because this IPv6 destination address has an IID that no host recognizes (as discussed recently on the mailing list), the packet will be discarded. A Destination-Unreachable ICMPv6 message is then returned to the BR anycast address. The BR statelessly converts it into an IPv4 ICMP error message returned to the IPv4 source.
If the path is direct from a CE of a 4V6 domain to another CE of the same domain, the ICMPv6 error message is returned to the source CE. This CE does the conversion to the right IPv4 ICMP message for the  CE NAT44.
Does this answer your concern? 

> Moreover, I think this issue would have distinct impact on stateless solutions and stateful ones. For stateful ones, the states in AFTR have already shown the binding information between IPv4 address/port set and IPv6 address explicitly. While for stateless ones, these address mapping rules are determined implicitly in algorithm. As a result, in order to reflect prefix mapping information (discussed in multiple prefix threads), some more rules would be needed to be introduced accordingly .

> Of course, the number of rules would be significantly less than the number of states .

Yes, that's the point.
The difference is between BR/AFTR's that have states _per customer prefix_ or just as many mapping rules as independent IPv4 prefixes. 

In addition, if several BR/AFTR's instances have to share their load for scalability, their per-customer states have to be identical. If per-customer states are dynamically updated this becomes complex.

Last but not least, if there is one mapping rule per independent IPv4 prefix, direct CE-to-CE paths are possible (each CE knows all mapping rules).  If BR/AFTR's have per-customer states, CE's don't know them. Direct CE-to-CE paths are impossible.

Hope it helps.

Kind regards,
RD

...

> 
> If a node is attached to an IPv6 network and ignores the static shared-address system of this network, it won't be able to receive/accept parameters of this-system mapping rule(s).

---

From: Qiong <[email-masked]>
Date: Sat, 30 Jul 2011 10:01:18 +0800

Hi Remi,

Thanks. I think your solution would work, but it still get ICMP Unreachable
message rather than normal communication packet.

Ok, I will keep silent and let's wait for Dave's answer :)

On Fri, Jul 29, 2011 at 3:42 PM, Rémi Després <[email-masked]>wrote:

> In the downstream direction from the Internet, the stateless BR (no per
> customer state) maps the destination transport-address to an IPv6
> destination address.
> Because this IPv6 destination address has an IID that no host recognizes
> (as discussed recently on the mailing list), the packet will be discarded. A
> Destination-Unreachable ICMPv6 message is then returned to the BR anycast
> address. The BR statelessly converts it into an IPv4 ICMP error message
> returned to the IPv4 source.
> If the path is direct from a CE of a 4V6 domain to another CE of the same
> domain, the ICMPv6 error message is returned to the source CE. This CE does
> the conversion to the right IPv4 ICMP message for the  CE NAT44.
> rules would be needed to be introduced accordingly .
>
>
> The difference is between BR/AFTR's that have states _per customer prefix_
> or just as many mapping rules as independent IPv4 prefixes.
>
> In addition, if several BR/AFTR's instances have to share their load for
> scalability, their per-customer states have to be identical. If per-customer
> states are dynamically updated this becomes complex.
>
> Last but not least, if there is one mapping rule per independent IPv4
> prefix, direct CE-to-CE paths are possible (each CE knows all mapping
> rules).  If BR/AFTR's have per-customer states, CE's don't know them. Direct
> CE-to-CE paths are impossible.
>
> Hope it helps.
>
> Kind regards,
> RD
>
> ...
>
>
>> If a node is attached to an IPv6 network and ignores the static