[shara] Configuration task at the CPE side (was RE: Summary and outcomes from aplusp BoF at IETF 76)

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de [e-mail]
Envoyé : mercredi 16 décembre 2009 18:14
À : [e-mail]
Cc : [e-mail]; [e-mail]; [e-mail]
Objet : Re: [shara] Summary and outcomes from aplusp BoF at IETF 76

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: [e-mail] [mailto:[e-mail]] On Behalf
>Of ext Rémi Després
>Sent: 10 December, 2009 13:19
>To: Ralph Droms
>Cc: IESG IESG; Chairs; [e-mail]; [e-mail]
>Subject: Re: [shara] Summary and outcomes from aplusp BoF at IETF 76
>
>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
>
>> Dear Ralph,
>>
>> Thank you for your answers but I still have some objections.
>>
>> Please see in line.
>>
>>
>> -----Message d'origine----- De : Ralph Droms
>> [mailto:[e-mail]] Envoyé : mercredi 9 décembre 2009 15:29 À :
>> BOUCADAIR Mohamed NCPI/NAD/TIP Cc : [e-mail]; IESG IESG;
>> Softwire Chairs Objet : Re: [shara] Summary and outcomes from aplusp
>> BoF at IETF 76
>>
>> Responses in line...
>>
>> On Dec 7, 2009, at 9:04 AM 12/7/09,
>> <[e-mail]
>>> <[e-mail]> wrote:
>>
>>> 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"?!
>>
>> 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.
>
>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!
>>
>> 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.
>
>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"
>> (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?
>>
>> 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?
>>
>> 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 subscriber-provided services"?
>>
>> a+p is out of scope for the softwire WG and no work is chartered
>> elsewhere.
>>
>>> Cheers, Med
>>
>> - Ralph
>>
>>
>>> -----Message d'origine----- De : [e-mail]
>>> [mailto:[e-mail]] De la part de Ralph Droms Envoyé :
>>> vendredi 4 décembre 2009 17:59 À : [e-mail] 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.
>>>
>>> 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
>>>
>>> _______________________________________________ shara mailing list
>>> [e-mail] 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
>> [e-mail] https://www.ietf.org/mailman/listinfo/shara
>>
>
>_______________________________________________
>shara mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/shara
_______________________________________________
shara mailing list
[e-mail]
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.
********************************