Subject: [shara] APLUSP minutes

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Dec 2009 09:03:08 -0800

APLUSP minutes are now at:
  http://www.ietf.org/proceedings/09nov/minutes/aplusp.txt

Due to a glitch in the audio archives the last 5 minutes of the meeting are
not in the audio archives and unfortunately the Jabber logs don't provide
additional detail.  We believe we have the last part of the meeting correct
but welcome corrections / clarifications -- as usual.

Thanks,
-Christian Jacquenet,
 Dan Wing

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 10:49:10 +0100

Dear all,

Thank you Dan for the minutes.

Jari Arkko stated "Mobile Networks are already v6-ready.  Not clear that we need
              more solutions."

What mobile networks are you talking about? Are you referring to operational networks or specification documents? 

The main drivers for the migration/introduction of IPv6 into mobile networks are: (1) IPv4 address exhaustion and (2) NAT performance degradation for some applications, not to mention M2M services and CAPEX issues. A+P provides an interesting solution to solve both (1)+(2) issues while encouraging the use of IPv6 transfer capabilities. Migration to IPv6-only network would be accelerated owing to A+P. Of course, the cost is that UEs should be support port restriction feature.

Why should IETF exclude a+p from the IPv6 migration toolkit? 
A pure dual stack approach does not solve (1) and (2) stated above. Is not this sufficient enough to motivate work on alternative solution(s)?

BTW, below a set of questions that need to be solved while dealing with IPv6 migration:
(a) How to deal with legacy UEs? 
(b1) How to avoid the cascaded NAT levels? How to avoid adherence to ALGs?
(b2) How to offload NAT44/64/64? How to avoid NAT664 tromboning?
(b3) Power/battery efficiency of UE when NAT devices are embedded in the core network.
(d) How to shorten the co-existence between v4 and v6?
(e) How to encourage "push" services that may be defined for mobile?
(f) How to encourage native communications while encouraging IPv6? (this may not be inline with "b/c")
(g) Do we have an exit strategy? Transition is a very complicated exercise, intermediary steps may stay for ever!

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : vendredi 4 décembre 2009 18:03
À : [email-masked]
Objet : [shara] APLUSP minutes

Thanks,
-Christian Jacquenet,
 Dan Wing

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 07 Dec 2009 22:01:26 +0900

> Why should IETF exclude a+p from the IPv6 migration toolkit? 

Because A+P makes IPv6 totally unnecessary.

We should remove the curse of IPv6, at least from the rest of the
world.

						Masataka Ohta

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 07 Dec 2009 14:07:02 +0100

> Because A+P makes IPv6 totally unnecessary.

Masataka,

Strongly disagree. A+P is a hack, interim solution to make transition period 
easier and was not meant as IPv6 replacement.

Regards, Jan Zorz

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 07 Dec 2009 22:19:04 +0900

Jan Zorz @ go6.si wrote:

> Strongly disagree. A+P is a hack, interim solution to make transition 
> period easier and was not meant as IPv6 replacement.

How long, do you think, the transition period will be?

Please be noted that 14 years have passed since RFC1883.

							Masataka Ohta

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 14:24:01 +0100

Dear all,

I fully disagree with this statement. 

A+P is not a replacement to IPv6. A+P is only an intermediary step for us to ease and encourage IPv6 migration to solve the problems we have.

Maintaining an A+P world with no exit strategy to IPv6 means that the issues described in http://tools.ietf.org/html/draft-ford-shared-addressing-issues-01 will be for ever there. This is not our position...

Cheers,
Med

-----Message d'origine-----
De : Masataka Ohta [mailto:[email-masked]] 
Envoyé : lundi 7 décembre 2009 14:01
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [shara] Mobile Networks are already v6-ready. Really? (was RE: APLUSP minutes)

						Masataka Ohta

---

From: Jari Arkko <[email-masked]>
Date: Mon, 07 Dec 2009 16:22:06 +0200

Mohamed,

> What mobile networks are you talking about? Are you referring to operational networks or specification documents? 

I was referring to the capabilities of existing cellular networks, or at 
least those employing 3GPP technology.

More specifically, I think we have the following situation in these 
networks: Initial specifications for IPv6 support were laid out in 1999 
(in a release called R99) and in proper form in the early 2000s (in the 
R5 release). Since then, network vendors have implemented these 
specifications, and today, many (most?) existing cellular networks use 
equipment that supports IPv6 for end-user traffic. This gives IPv4 and 
IPv6 access through the mobile network. The mobile networks employ 
tunneling technology for mobility, and as a side effect this separates 
the IP versions that the network itself uses from the IP versions that 
are offered to user traffic. This means that users can turn on IPv6 
before the entire operator's network is doing IPv6 on every node, or 
vice versa.

Don't get me wrong. I'm not claiming that this is a huge success or that 
your subscription comes with IPv6 service. I am claiming that the 
*network* equipment supports IPv6 and dual stack traffic. However, there 
are several remaining issues:

(1) Operators have generally not turned IPv6 on in commercial service.

(2) Many handsets support IPv6, but most do not

(3) Even if the network equipment for the cellular network supports 
IPv6, there is no guarantee that the IP connectivity, routing, etc. at 
the core of that operator's network also supports IPv6.

(4) If we turned all this on tomorrow on every network and every access 
point name, I'm sure we'd run into lots of implementation bugs in hosts, 
misconfigurations in the IPv6 routing system at the operator network, etc.

(5) There are many special situations where we still need new 
functionality in the products (say, prefix delegation for IPv6 routers 
or support for running the signaling network in IPv6 only)

I am saying, however, that for this particular segment of the market, 
perhaps we need more people flipping the switch and turning IPv6 on than 
anything else (e.g., flipping the switch is far more important than 
developing some new technology).

More information at http://ipv6ws.arkko.com/report.html

Jari

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 16:16:46 +0100

Dear Jari,

Thank you for this clarification. Please see inline.

-----Message d'origine-----
De : Jari Arkko [mailto:[email-masked]] 
Envoyé : lundi 7 décembre 2009 15:22
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [shara] Mobile Networks are already v6-ready. Really? (was RE: APLUSP minutes)

Mohamed,

Med: I understand the point even if it is not so that simple since the "presence" of IPv6 stack does not mean the support of IPv6.
Proper IPv6 validation campaigns are to be undertaken. For the already deployed nodes, I'm afraid to say that this was not the case. 
Furthermore, we have other requirements such the ability to service the legacy UEs, to deliver the same services (with the same level of QoE) to both IPv4 and IPv6-enabled UE, how to ensure that service may be delivered to the UE even in roaming situations, etc.

Med: Just a clarification: we are not proposing a new technology but a smooth IPv6 migration method:
- Solve the IPv4 address shortage by sharing the same IPv4 address among several devices/customers;
- May be deployed with an IPv6-only network. Only IPv6 provisioning means may be used to provision IPv6 prefix and port ranges;
- No stateful function is required to be deployed in the core network for IPv4-IPv6 interconnection and IPv4-IPv4 communications;
- It does not require a universal agreement to move to IPv6: a local domain may decide to migrate to IPv6 while offering in a stateless manner both IPv4 and IPv6 connectivity services. Only IPv6 transfer capabilities are required to handle received (at ingress points of PLMN) IPv4/IPv6 traffic;
- Does not require any NAT function in the core network. Push services may be deployed (modulo port restriction);
- No impact on the routing protocols: native IPv6 routing behaviour is required. No port-inferred routing protocol is required.

A+P is to be put in the same level as DS deployment scheme. BTW, DS does not solve the IPv4 address exhaustion (since an IPv4 address is required to be assigned to the DS UE. Alternative means such as dynamic activation of IPv4 PDP context/bearer may mitigate this issue but it needs to be standardised) and except the use of protocol translation function, no guidelines are elaborated to encourage native communications and avoid crossing protocol translation devices. If a NAT function is introduced in the PGW/GGSN or even deeper in the network to solve the IPv4 @ depletion, DS does not solve the hurdles encountered by NAT sensitive applications (not only current applications but forthcoming ones also).

I'm not claiming that A+P is ** the solution ** but that A+P should be part of the IPv6 toolkit. It is up to the SPs to decide what is the best solution which meets their requirements. 

Cheers,
Med

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Dec 2009 12:35:36 +0900

[email-masked] wrote:

> If a NAT function is introduced in the PGW/GGSN or even deeper
> in the network to solve the IPv4 @ depletion, DS does not solve
> the hurdles encountered by NAT sensitive applications (not only
> current applications but forthcoming ones also).

As end to end NAT does not have hurdles for the current and forthcoming
applications, ISP network may use NAT.

> I'm not claiming that A+P is ** the solution ** but that A+P should
> be part of the IPv6 toolkit.

As A+P is unnecessarily combined with leagacy NAT, its hurdle is
as bad as that of CGN/LSN.

						Masataka Ohta