> Le 2 nov. 2010 à 17:08, Dan Wing a écrit : > > >> For clarification, is your comment just a positive remark about > SCTP, > >> or is it suggesting that SCTP could work without hosts knowing their > >> global addresses. > >> (If it is the former, it doesn't go against what I wrote; if it is > the > >> latter, I don't see how it can work.) > > > > SCTP's ASCONF (Address Configuration Change) allows using 0 (::0, > 0.0.0.0) > > to handle that case, as briefly described on page 6 of RFC5061 and > page 17 > > of draft-ietf-behave-sctpnat-03. > > Thanks, Dan, for the pointer. > I hadn't read draft-ietf-behave-sctpnat-03 before.
It relies on an extension to SCTP, the DISABLE_RESTART parameter (described in draft-stewart-natsupp-tsvwg). I do not fully understand the side-effects of DISABLE_RESTART. To my mind, because an SCTP client never knows if there is a NAT between itself and the SCTP server, the SCTP client would always need to send the DISABLE_RESTART parameter. > 1. > Since the proposed ASCONF mechanism relies on NATs to support it by an > ad hoc stateful function, this doesn't concern the proposed stateless > NAT66. The ASCONF mechanism is not "proposed" -- it is in RFC5061 where it says: If the address 0.0.0.0 or ::0 is provided, the receiver MAY lookup the association by other information provided in the packet. my reading of those tea leaves is "look up the association using the source IP address". > It therefore remains true that NAT66 and SCTP are incompatible. > Right? I disagree. An SCTP client can absolutely establish a connection across a NAT66. So SCTP does work -- it doesn't outright break. If there are multiple egress paths, each with their own NAT66 -- something like shown in the diagram at http://tools.ietf.org/html/draft-ietf-behave-sctpnat-03#section-4.2 (and reproduced below for the archives) -- the SCTP client would need to send ::0 in its ASCONF and the SCTP server would need to interpret ::0 to mean "use the source IP address", which is only a MAY in RFC5061. It is true that if the SCTP client or the SCTP server don't use ::0 in ASCONF, that the SCTP connection cannot get the benefit of ASCONF. But the rest of SCTP works fine. Note that ASCONF is only one of the features of SCTP (RFC5061, " Dynamic Address Reconfiguration"); it is not "SCTP" (RFC4960) and even if ASCONF was described in the base SCTP specification, it's one feature. A statement I could agree with regarding NAT66 and SCTP is more along the lines of "NAT66 will break one of SCTP's features (RFC5061, Dynamic Address Reconfiguration), if the SCTP client or SCTP server do not support ASCONF containing an IP address of ::0." Diagram from Section 4.2 of draft-ietf-behave-sctpnat-03, Internal | External +------+ /---\/---\ +---------+ /=======|NAT A |=========\ / \ +---------+ | SCTP | / +------+ \/ \ | SCTP | |end point|/ ... | Internet |=====|end point| | A |\ \ / | B | +---------+ \ +------+ / \ / +---------+ \=======|NAT B |=========/ \---\/---/ +------+ | > 2. I may have some questions about the example of draft-ietf-behave- > sctpnat-03 page 17. > If yes, I will pursue off list (the subject has no relationship with > stateless NAT66) There has been scant review of SCTP NAT in BEHAVE, which I have found distressing. I look forward to your comments. -d _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
