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

["Andreas Ripke" <[e-mail]>]

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



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Thursday, December 17, 2009 7:48 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:
> 
> 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]; softwire-
> [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.
> ********************************
> 
> _______________________________________________
> shara mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/shara