Subject: [shara] Summary and outcomes from aplusp BoF at IETF 76

From: Ralph Droms <[email-masked]>
Date: Fri, 4 Dec 2009 11:58:46 -0500

Thanks to Dan and Christian for chairing the BoF and to everyone who
participated.  I especially thank the participants for staying on
topic and having a constructive and useful discussion of the issues
during the BoF.

There were a couple of aspects of the BoF that I wish I had handled
better.  In particular, I didn't intend to exclude any of the
proponents of the various a+p proposals related to dual-stack lite
(DS-lite) and, in retrospect, we could have done a better job with the
initial formulation of the questions asked at the end of the BoF.
I'll reiterate that I think the chairs did a great job with the BoF,
considering the history and context of the topic, and the shortcomings
of the BoF are really my responsibility.

However, I think that this BoF, considered with the outcome of the
previous shara BoF, came to a couple of useful conclusions:

* there is a need to provide inbound connections to
   subscriber-provided services, and
* a+p has too many side effects, not all of which are known at this
   point, to be a useful mechanism to meet that need.

Comments on these conclusions is encouraged...

Considering this outcome, no work on a+p will be chartered.  I will
ask the softwire WG to consider the issue of inbound connections to
subscriber-provided services as part of their work on DS-lite.  Other
working groups may take on development of techniques for providing
inbound connections in other technologies and scenarios.

- Ralph

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 07 Dec 2009 21:57:15 +0900

>   subscriber-provided services, and

That's trivially easy with end to end NAT. Moreover, A+P can be
improved to be A+P--, which is fully transparent end to end, by
removing legacy NAT functionality of CPE.

For further port sharing, CPE of A+P-- may also act as a gateway
of end to end NAT.

>   point, to be a useful mechanism to meet that need.

The consensus on this mailing list, so far, is that Dave Thaler
speculated too many side effects none of which are known to exist. 

If you disagree, please describe a side effect or two in reasonable
detail.

						Masataka Ohta

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 15:04:22 +0100

Dear Ralph,

You mentioned that "a+p has too many side effects, not all of which are known at this
   point, to be a useful mechanism to meet that need."

- Could you enumerate these "too many side effects"? BTW, It is strange to have an objection to work an A+P because "not all of which are known at this
   point"?! 
- Are these issues specific to A+P?
- Should we do the same exercise for other forms of shared address schemes?
- Should we understand that the underlying message from the IESG is to go for a CGN-based solution? Quid of maintaining ALGs, service brokenness, lawful data storage, robustness, etc.? If CGN are massively deployed, what will be the motivation to move to IPv6? Again: what is the exit strategy proposed by the IESG. I'm afraid to say that DS is not a viable one!

You mentioned "I will
ask the softwire WG to consider the issue of inbound connections to
subscriber-provided services as part of their work on DS-lite. "

- Does it mean that only port forwarding policies and configuration of static mappings in the AFTR (BTW, the AFTR terminology is misleading since the ds-lite CGN is not an AF translator) will be in scope?
- Does it mean that A+P features MAY be supported in B4 and AFTR? Or a+p is explicitly out of scope of the solution candidates to solve "connections to
subscriber-provided services"?

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ralph Droms
Envoyé : vendredi 4 décembre 2009 17:59
À : [email-masked]
Cc : IESG IESG; Softwire Chairs
Objet : [shara] Summary and outcomes from aplusp BoF at IETF 76

- Ralph

_______________________________________________
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: Ralph Droms <[email-masked]>
Date: Wed, 9 Dec 2009 09:28:33 -0500

Responses in line...

On Dec 7, 2009, at 9:04 AM 12/7/09, <[email-masked] 
 > <[email-masked]> wrote:

> - Could you enumerate these "too many side effects"? BTW, It is  
> strange to have an objection to work an A+P because "not all of  
> which are known at this
>   point"?!

Let me clarify.  Dave Thaler's presentation pointed out enough side  
effects specific to A+P to lead to the conclusion.  I assume other  
side effects would be discovered in the course of developing an a+p  
specification.

> - Should we understand that the underlying message from the IESG is  
> to go for a CGN-based solution? Quid of maintaining ALGs, service  
> brokenness, lawful data storage, robustness, etc.? If CGN are  
> massively deployed, what will be the motivation to move to IPv6?  
> Again: what is the exit strategy proposed by the IESG. I'm afraid to  
> say that DS is not a viable one!

There is no silver bullet to be found anywhere.  We have some  
solutions, which we need to deploy as judiciously as possible while we  
move the Internet to IPv6.  The existing interim technologies have  
known problems; I interpret the response in the BoF to indicate that a 
+p is not considered to be less problematic or otherwise advantageous  
relative to the existing technologies.

> - Does it mean that only port forwarding policies and configuration  
> of static mappings in the AFTR (BTW, the AFTR terminology is  
> misleading since the ds-lite CGN is not an AF translator) will be in  
> scope?

If I understand your question correctly, yes, I will ask the softwire  
WG to develop control mechanisms for forwarding in the AFTR.

> - Does it mean that A+P features MAY be supported in B4 and AFTR? Or  
> a+p is explicitly out of scope of the solution candidates to solve  
> "connections to

a+p is out of scope for the softwire WG and no work is chartered  
elsewhere.

- Ralph

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Wed, 09 Dec 2009 16:12:41 +0100

> a+p is out of scope for the softwire WG and no work is chartered elsewhere.

Ralph, hi.

What are proposed next steps to make some progress on that matter?

Regards, Jan Zorz

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 07:34:43 +0100

Dear Ralph,

Thank you for your answers but I still have some objections.

Please see in line.

-----Message d'origine-----
De : Ralph Droms [mailto:[email-masked]] 
Envoyé : mercredi 9 décembre 2009 15:29
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]; IESG IESG; Softwire Chairs
Objet : Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

Responses in line...

Med: I'm afraid to disagree here since D. Thaler's presentation is mostly a collection of issues which are not specific to
A+P (Please refer to http://www.ietf.org/mail-archive/web/shara/current/msg00196.html).
Particularly, the "Long-term impact" slide from D. Thaler prezo is not so that true since the proposed A+P solutions allow a smooth migration
to IPv6 while solving the IPv4 address exhaustion. 
- A+P solutions encourage the deployment of IPv6 in local domain without requiring universal agreement
to move to IPv6 since interconnection functions at the boundaries are stateless. 
- A+P allows also to shorten the lifetime of the dual-stack plans in
the network and only IPv6 is required for the delivery of IPv4 and IPv6 connectivity services. 
- Services are not broken since we don't need any ALG to be deployed in the core network. 
- A+P is not a hurdle for the introduction of new services since there is no need to update intermediary nodes (such as CGNs). 
- A+P does not need any state synchronisation for robustness reasons since now per-flow data is maintained in intermediary nodes.
- A+P allows to offer subscriber-hosted services with current practices. No need to define new protocols (some modifications
are required to avoid port conflict)
- Already defined tools and techniques (e.g., URL, SRV records, redirection, etc.) allows to specify a port number in the host part
- Etc.

Med: I wasn't in the BoF, but reading the mail from M. Wasserman makes me think that there was something "wrong"
(http://www.ietf.org/mail-archive/web/shara/current/msg00195.html).
So, why not give us a second chance to better explain the problem we are targeting and explain the rationale of the solutions we are proposing?

- Ralph

---

From: Rémi Després <[email-masked]>
Date: Thu, 10 Dec 2009 12:18:47 +0100

Ralph,

It's IMHO constructive that Mohamed made the effort to continue this 
discussion.

First, I agree with the list of positive points of A+P he listed.
It is a useful contribution to balance the list of negative points
of Dave's presentation in Hiroshima. (This list BTW has been challenged 
during the BOF, with too little time to argue technically).

I agree also with Margaret's view that the BOF process has been
sufficiently unusual for the chairs' conclusion to be open to revision.

In addition, I note that:
o The scope of the BOF has been firmly limited to A+P *in the context of
DS-lite*.
Any conclusion, contested or not, must therefore be also limited to this
context.
As a minimum, A+P in the mesh-softwire context can therefore by no means 
be considered as ruled out.
o At the end of the Softwire meeting, time being too short, I introduced
in 5 minutes a 28 pages draft on a mesh-softwire lite approach. This
approach, derived from 6rd, i.e. intended for simple and short term
deployment, includes a variant of A+P as a feature.
I was told that more time should be available for it at the next IETF
meeting, which is fair in view of the time that was available.

More comments in line.

Conclusion (as Mohamed wrote):
"Why not give us a second chance to better explain the problem we are
targeting and explain the rationale of the solutions we are proposing?"

Regards,

RD

> -----Message d'origine----- De : Ralph Droms
> [mailto:[email-masked]] Envoyé : mercredi 9 décembre 2009 15:29 À :
> BOUCADAIR Mohamed NCPI/NAD/TIP Cc : [email-masked]; IESG IESG;
> Softwire Chairs Objet : Re: [shara] Summary and outcomes from aplusp
> BoF at IETF 76
> 
> Responses in line...
> 
>> You mentioned that "a+p has too many side effects, not all of which
>>  are known at this point, to be a useful mechanism to meet that
>> need."
>> 
>> which are known at this point"?!
> 

Why to assume this?
Why not to assume also, or instead, that some of the listed side effects
are inexistent, even in the sole DS-lite context (as everal participants
knowing the subject said it during the BOF).
(I have a very great respect for Dave's contributions in general, but 
this one was clearly not at the usual level.)

> Med: I'm afraid to disagree here since D. Thaler's presentation is
> mostly a collection of issues which are not specific to A+P (Please
> refer to
> http://www.ietf.org/mail-archive/web/shara/current/msg00196.html). 
> Particularly, the "Long-term impact" slide from D. Thaler prezo is
> not so that true since the proposed A+P solutions allow a smooth
> migration to IPv6 while solving the IPv4 address exhaustion. - A+P
> solutions encourage the deployment of IPv6 in local domain without
> requiring universal agreement to move to IPv6 since interconnection
> functions at the boundaries are stateless. - A+P allows also to
> shorten the lifetime of the dual-stack plans in the network and only
> IPv6 is required for the delivery of IPv4 and IPv6 connectivity
> services. - Services are not broken since we don't need any ALG to be
> deployed in the core network. - A+P is not a hurdle for the
> introduction of new services since there is no need to update
> intermediary nodes (such as CGNs). - A+P does not need any state
> synchronisation for robustness reasons since now per-flow data is
> maintained in intermediary nodes. - A+P allows to offer
> subscriber-hosted services with current practices. No need to define
> new protocols (some modifications are required to avoid port
> conflict) - Already defined tools and techniques (e.g., URL, SRV
> records, redirection, etc.) allows to specify a port number in the
> host part - Etc.
> 
> 
>> - Are these issues specific to A+P? - Should we do the same
>> exercise for other forms of shared address schemes? - Should we
>> understand that the underlying message from the IESG is to go for a
>> CGN-based solution? Quid of maintaining ALGs, service brokenness,
>> lawful data storage, robustness, etc.? If CGN are massively
>> deployed, what will be the motivation to move to IPv6? Again: what
>> is the exit strategy proposed by the IESG. I'm afraid to say that
>> DS is not a viable one!
> 
> solutions, which we need to deploy as judiciously as possible while
> we move the Internet to IPv6.  The existing interim technologies have
>  known problems; I interpret the response in the BoF to indicate that
> a +p is not considered to be less problematic or otherwise
> advantageous relative to the existing technologies.

NATs are unavoidable and very useful in various scenarios, but they are
also THE major cause of many complex problems.
In particular, they are responsible for the high sophistication of such
interim technology as Teredo.

Suggesting, as Dave did, that A+P will be at least as problematic as
Teredo, is wrong, and very misleading:
o Unlike NATs and Teredo, A+P can be stateless (a property that BTW
fosters the interest for 6rd) .
o If combined with CGNs, A+P is AFAIK the simplest known approach for 
incoming connections.

> 
> Med: I wasn't in the BoF, but reading the mail from M. Wasserman
> makes me think that there was something "wrong" 
> So, why not give us a second chance to better explain the problem we
> are targeting and explain the rationale of the solutions we are
> proposing?
> 
> You mentioned "I will
>> misleading since the ds-lite CGN is not an AF translator) will be
>> in scope?
> 
>> - Does it mean that A+P features MAY be supported in B4 and AFTR?
>> Or a+p is explicitly out of scope of the solution candidates to
>> solve "connections to subscriber-provided services"?
> 
>> Cheers, Med
>> -----Message d'origine----- De : [email-masked]
>> [mailto:[email-masked]] De la part de Ralph Droms Envoyé :
>> vendredi 4 décembre 2009 17:59 À : [email-masked] Cc : IESG IESG;
>> Softwire Chairs Objet : [shara] Summary and outcomes from aplusp
>> BoF at IETF 76
>> 
>> Thanks to Dan and Christian for chairing the BoF and to everyone
>> who participated.  I especially thank the participants for staying
>> on topic and having a constructive and useful discussion of the
>> issues during the BoF.
>> 
>> (DS-lite) and, in retrospect, we could have done a better job with
>> the initial formulation of the questions asked at the end of the
>> BoF. I'll reiterate that I think the chairs did a great job with
>> the BoF, considering the history and context of the topic, and the
>> shortcomings of the BoF are really my responsibility.
>> 
>>  ask the softwire WG to consider the issue of inbound connections
>> to subscriber-provided services as part of their work on DS-lite.
>> Other working groups may take on development of techniques for
>> providing inbound connections in other technologies and scenarios.
>> 
>> - Ralph
>> 
>> _______________________________________________ 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. 
> ********************************* 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. ********************************
> 
> _______________________________________________ shara mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/shara
>

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 13:17:52 +0100

Hi Ralph,

Yes and we must not consider Dave Thaler's presentation as the IETF consensus.
-The slides only showed up at the beginning of the BoF session, so they couldn't be discussed on the mailing list beforehand (no reference draft either).
-Due to lack of time they couldn't really be discussed during the BoF.
-As noticed in the minutes: Problem statement clear/not clear: hum was louder for "not clear", meaning people didn't understand what was at stake.

So I would like to back Margaret's proposal:
"From an IETF process standpoint, I think that the best thing we can  
do with the outcome of the aplusp BOF is to ignore it completely"

A+P deserves further consideration and discussion

Regards,

Pierre 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : jeudi 10 décembre 2009 12:19
À : Ralph Droms
Cc : IESG IESG; Chairs; [email-masked]; [email-masked]
Objet : Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

Ralph,

More comments in line.

Regards,

RD

Why to assume this?

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 10 Dec 2009 21:48:10 +0900

> during the BOF, with too little time to argue technically).

As I challenged with running code during the BoF, there was no more
technical discussion necessary to dismiss it, which was why people
in the BoF could not have argued against A+P based on it.

After the BoF, his presentation was totally dismissed with no one,
not even Dave Thaler himself, actively supporting its validity.

						Masataka Ohta

---

From: <[email-masked]>
Date: Wed, 16 Dec 2009 18:14:29 +0100

Hello,

In the BOF there seemed to be lots of concern about host changes. Too bad I was unable to participate. 

I wanted to clarify still that the A+P technology includes OPTIONAL host side support: by the drafted design a host can easily continue using NATted private IPv4 address as usually. Only if a host so chooses, it MAY utilize A+P to gain direct access to public IPv4 address. Furthermore, the optional host side NAT support is not very complex thing to do AFAIK: e.g. doable in Linux with iptables that already supports restriction of the external ports used in NATtting. 

Additionally, the entropy of port randomization can be reserved as has been documented (but I acknowledge that would require implementation changes also in Linux).

I would like to understand better where the big concern for the host side impacts come from, remembering A+P does not require host changes?

Best regards,

Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of ext Rémi Després
>Sent: 10 December, 2009 13:19
>To: Ralph Droms
>Cc: IESG IESG; Chairs; [email-masked]; [email-masked]
>Subject: Re: [shara] Summary and outcomes from aplusp BoF at IETF 76
>
>Ralph,
>

---

From: <[email-masked]>
Date: Thu, 17 Dec 2009 07:47:45 +0100

Dear Teemu, all,

As you mentioned, the configuration of the port restriction feature on Linux (CPE side) does not require huge effort. Two command lines are required (one for TCP and one for UDP) for a contiguous port range:

The command line for TCP is as follows:
  
 "iptables -t nat -A POSTROUTING -p tcp -o [Eth_EXT] -j SNAT --to-source [IPv4-pub]:[ports-range]"

With: "IPv4-pub" is the shared IPv4 address and the "ports-range" is the Port Range assigned to the CPE.

A similar line is to be enforced also for UDP.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 16 décembre 2009 18:14
À : [email-masked]
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

Hello,

Best regards,

Teemu

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Dec 2009 19:17:40 +0900

> I would like to understand better where the big concern for the host
> side impacts come from

scare tactics

---

From: "Andreas Ripke" <[email-masked]>
Date: Fri, 18 Dec 2009 16:33:45 +0100

Teemu,

Just a brief hint.
Make sure to use a 2.6 kernel version for iptables' SNAT with port
ranges as described below by Med. For some reasons I tried 2.4.35
(mips) and it didn't handle the max value of the port range properly.
With 2.6.25 it works fine.

Andreas

> Of [email-masked]
> Sent: Thursday, December 17, 2009 7:48 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [shara] Configuration task at the CPE side (was RE: Summary
> and outcomes from aplusp BoF at IETF 76)
> 
> 
> Dear Teemu, all,
> 
> As you mentioned, the configuration of the port restriction feature on
> Linux (CPE side) does not require huge effort. Two command lines are
> required (one for TCP and one for UDP) for a contiguous port range:
> 
> I wanted to clarify still that the A+P technology includes OPTIONAL
> host side support: by the drafted design a host can easily continue
> using NATted private IPv4 address as usually. Only if a host so
> chooses, it MAY utilize A+P to gain direct access to public IPv4
> address. Furthermore, the optional host side NAT support is not very
> complex thing to do AFAIK: e.g. doable in Linux with iptables that
> already supports restriction of the external ports used in NATtting.
> 
> Additionally, the entropy of port randomization can be reserved as has
> been documented (but I acknowledge that would require implementation
> changes also in Linux).
> 
> side impacts come from, remembering A+P does not require host changes?
> 
> Best regards,
> 
> Teemu
> 
> >>> - Could you enumerate these"too many side effects"? BTW, It is