Dear So-Called chairs, (you did ask for that one! ;-)) > Following up on the 'stateless' thread from a wg chair perspective. > > 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. > > 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.
indeed you can. then you loose the benefit of the stateful solution of offering port entropy. the important points for the stateless solutions are: - direct CE to CE traffic (statful is hub and spoke) architecture - no new state to be maintained, or recovered, or scaled for in the network - implicitly does prefix delegation, full or shared IPv4 address provisioning > 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. see RFC1958: ..."This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible." the stateful solutions add new state in the middle of the network. this state has to be maintained and recovered in case of failure. the stateless solution does not. when we refer to 'state' here, we are talking about state in the network. you can argue if a CE is the real end point or not, regardless the stateless class of solutions do not introduce any _new_ state. > 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... the stateless solutions on the table can do more than just address sharing. but, to your point. all solutions that we are discussing for prolonging the life of IPv4 are based on address sharing. the issues discussed apply to all the IPv4 address sharing mechanisms, doesn't it?CGNs (NAT444 or DS-lite) or A+P variants. > 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. I don't understand what is asked for here? or how a small number of volunteers are going to 'frame' the discussion? does it mean 5 of us sitting on Randy so he doesn't get to the mike? I'm happy to volunteer then. ;-) appears to me we are having the discussion on the mailing list. based on what has been posted to this thread(s) and the discussion at the last IETF meeting, let us accept the draft as a working group item, and start working on it as a wg. the draft more than justifies why a stateless solution is needed, I don't want to see us spend the discussion time in Quebec on state versus no state. the Internet community made that choice when I was still in diapers. cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
