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

[<[e-mail]>]

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