Le 30 oct. 2010 à 00:53, Margaret Wasserman a écrit : > > On Oct 29, 2010, at 9:16 AM, Rémi Després wrote: >> 1. >> - Some consider that some form of NAT66 is useful for some real customer >> needs. >> - Clear descriptions of which scenarios benefit from which type of NAT66 are >> however still missing. (At this stage, this seems to only be scenarios where >> baring all incoming connectivity is found desirable, but more precisions are >> lacking.) >> - If, once documented, such scenarios are convincing, documenting in IETF >> NAT66 characteristics that fit them will make sense. > > I do not consider this to be an accurate summary of arguments in favor of > publishing NAT66. > > The NAT66 document clearly states a use case for NAT66 that does _not_ rely > on blocking all incoming connections: address independence
In my understanding, address independence is a (useful) "feature", but not a "use case" per se. The complete description of a use case would permit to discuss. The draft says (asterisks added): "NAT66 provides a simple and *compelling* solution to meet the Address Independence requirement in IPv6". I don't see this a compelling at all. SAM, applied to IPv6-in-IPv6 tunneling (the SAM/TRAM application), does provide Address Independence and, to hosts that support it, does it without sacrificing incoming connectivity. (BTW, I will be happy to answer any clarification questions you may have about SAM, in Beijing in particular.) > In discussions on the nat66 list, enterprise administrators have confirmed > that this is a valid need, and that NAT66 would allow some enterprises that > are currently blocking on the need for NAT in IPv6 to deploy IPv6 in their > enterprises. I don't think I negated that. Yet, I am interested in looking to the explicit configuration and functional requirement of at least one of them, so that we can ask for clarification on what we don't understand. (In particular, it isn't clear to me that, in their particular cases, they couldn't remain IPv4-only until more complete solutions are available.) > There _also_ seem to be use cases where enterprise administrators use NAT > specifically for the purpose of blocking (most or all?) incoming connections. > I do not know if we have explored that use cases well enough to know if it > could be served by a stateful firewall and/or a combination of NAT66 and a > stateful firewall. I think it would make sense for the IETF to look into > those use cases in more detail, as was already done for CPE equipment. Agreed. > >> 2 >> - Some contributors advocate that "NAT66" should only designate *stateless >> NAT66*. > > You are the only person I have heard make that statement. Yet the statement is true, unless you negate that "Some contributors advocate that "NAT66" should only designate *stateless NAT66*. > If others hold this opinion, they should share it with me. I read several e-mails including talking about "stateful NAT66". In my understanding, stateful NAT66 is generally understood as a particular case of NAT66. If this is so, NAT66 can't designate ONLY stateless NAT66. I haven't heard arguments against this logic. If opinions are shared on this subject, it should IMHO be shared *on the list*. >> - 6to4-PMT is a proposal to add stateless NAT66's to 6to4 relays (without >> tool available for customers to know that their 6to4 addresses are now >> translated). > > I am unfamiliar with this proposal, so I can't comment on it. You could ask James Woodyatt (a great friend of 6to4), or look at what he wrote to v6ops, to see how harmful it would be to 6to4. Regards, RD _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
