Subject: [BEHAVE] question about draft-zhang-behave-nat64-load-balancing

From: [email-masked]
Date: Fri, 1 Jul 2011 12:03:50 +0800

Hello Mr zhang and all,

Zhenqiang Li from China Mobile. Two question about the draft.

1. Why the following is a problem? Traditional NAT44 also has this problem. The privacy extension enven encourages user to change its source address.
    A user accessing multiple IPv4 servers may be represented by multiple public IPv4 addresses since its traffic may be processed by different NAT64 systems.
 
2. Accordingly, in the section of  basic load balancing considerations, I do not think the following is a problem. The widely-deployed NAT44 can not even guarantee this point. 
The load balancing SHOULD persevere the assignment of the same external IPv4 address for all active sessions initiated by an IPv6-only host.

Best Regards,
Zhenqiang Li

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 30 Jun 2011 22:23:40 -0700

Hi Zhengjiang,

> 1. Why the following is a problem? Traditional NAT44 also has this problem. The privacy extension enven encourages user to change its source address.

Regarding privacy extensions, RFC4941 section 3.6 explicitly notes
this risk of changing the address.  I believe the expired addresses
can still receive open sessions but do not initiate new ones ... but i
suppose this depends on the implementation.... Yet, this is an IPv6
behavior, not an IPv4 and therefore not entirely germane to your
question.

>    A user accessing multiple IPv4 servers may be represented by multiple public IPv4 addresses since its traffic may be processed by different NAT64 systems.

This is likely to cause a challenge for any protocol that have
separate command and bearer channels, like SIP, PPTP, RTSP, and IPsec.
 It is unlikely that your IPsec session will work correctly if the
peer receives IKE from one IPv4 address and ESP/UDP from another
address.  Most CGNs i have seen allow for address persistence to avoid
this challenging behavior.

In my testing, if i recall correctly, I believe Microsoft Web Outlook
and the Juniper SSL client also fail when more than one address is
used.

> The load balancing SHOULD persevere the assignment of the same external IPv4 address for all active sessions initiated by an IPv6-only host.

I think all major CDNs do persistence today

OpenBSD can do persistence with the "source-hast" key words
http://www.openbsd.org/faq/pf/pools.html

Juniper example
http://kb.juniper.net/InfoCenter/index?page=content&id=KB6374

I am pretty sure all major CGN providers see this as a basic feature
that has substantial benefit.

This behavior is also referenced in rfc4787 and
draft-ietf-behave-lsn-requirements-01

"REQ-1:  A CGN MUST have an "IP address pooling" behaviour of
      "Paired".

   Justification:  This is a stronger form of REQ-2 from [RFC4787].

      Note that this requirement applies regardless of the transport
      protocol.  In other words, a CGN must use the same external IP
      address mapping for all sessions associated with the same internal
      IP address, be they TCP, UDP, ICMP, something else, or a mix of
      different protocols.
"

> Best Regards,
> Zhenqiang Li
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>