Hi Mark, It seems that the chairs have some concerns on the a+p transition technology which I understand.
However here in so-called stateless solution, a+p is used in a very specific context, removing most of the concerns, at least to me. Regards, Behcet > > > >Let's have discussion on the list instead, k? > > >On Jul 7, 2011, at 3:38 PM, Alain Durand wrote: > >Following up on the 'stateless' thread from a wg chair perspective. The thread was nothing but an announcement that the draft was present, and a bunch of people saying that they support it. >Yong and I are preparing a discussion FOR the Quebec meeting on the so-called >stateless solution. > >There are a number of points in the current draft that need discussion. >Sure, based on your review of the document that's fine. But, not "the thread >from a WG chair perspective" as stated above. That's ridiculous. > > >For example, no logging has been presented as a strong reason to do sateless. >However, no logging can be achieved >>with static port allocation on a centralized NAT. On this particular logging >>point, there are no obvious differences between the >>'distributed on CPE' NAT solution and the centralized NAT solution. >> As you point out, the "no logging" part is really a function of the use of a static mapping to a range of ports. Any centralized NAPT function can use static mapping. When you use static mapping, then you get all the pros and cons that go along with it. More generally, it seems that what is described as a 'stateless' solution should be characterized as a >'distributed state' solution. As such, the tradeoff of maintaining the state >centrally vs globally >needs to be analyzed. > "stateless operation" if you prefer. The point is that within the ISP network, there is no per-flow state that resides on any single endpoint running the protocol in question. So, config can be static, and BRs can be reached via anycast. That's the heart of a stateless solution. Just like 6rd, if you will. Also, it is not clear from this document which set of issues listed in RFC6269 are mitigated and which ones are not. >In particular, I'd hold that a so-called 'stateless' solution does not change >anything about the recommendations in RFC6302/BCP162 >that are derived from RFC6269... > RFC6302/BCP162 is a Standards track document that makes an informational reference to an Informational RFC 6269, so I would hardly call that "derived from," else we would likely have a downref issue that would have needed to be called out during IETF Last call for RFC 6302. In any case, RFC 6269 has some very good information. In fact, it very correctly states: Whether we're talking about DS-Lite, A+P, NAT64, or CGN isn't especially important -- it's the view from the outside that matters, and given that, most of the issues identified below apply regardless of the specific address sharing scenario in question. So, since most of the issues don't matter between stateful vs. stateless (A+P), we can dismiss most of this document pretty quickly for this comparison. Here are a couple of issues that do seem to matter though: Section 13.4 Port Randomization - here the culprit is use of a static mapping again, and essentially the other side of the coin for "no logging". Put simply, if you want to reduce your logging with a predictable port, you also make your port more guessable by an attacker. . Section 18: Single Points of Failure - here, stateless wins pretty much hands down as it is not introducing any new single points of failure. Perhaps there are a few more, but "most" should be insignificant by the own document's admission. We, chairs, would like to prepare a 'organized' discussion around these points (and others). We need a small number of >volunteers to help frame this discussion. Please contact me and Yong directly >if > >you want to help. >This is an important topic, and we intend to make sure there is ample time for >discussion in Quebec. > Why don't we just discuss it on the list and have a consensus call instead? If we had a thread of 200 messages as we did for moving 6to4 to historic, OK maybe we need to have a big coordinated discussion. But, I'm not seeing anything on the thread here that would suggest that we need to spend a lot of time preparing some big discussion among a group of people you and Yong select. - Mark > - Alain. > >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
