Please see inline. Cheers, Med -----Message d'origine----- De : Dan Wing [mailto:dwing@xxxxxxxxx] Envoyé : jeudi 5 mars 2009 18:26 À : BOUCADAIR Mohamed RD-CORE-CAE; sipping@xxxxxxxx Objet : RE: TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt > -----Original Message----- > From: mohamed.boucadair@xxxxxxxxxxxxxxxxxx > [mailto:mohamed.boucadair@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, March 04, 2009 10:34 PM > To: dwing@xxxxxxxxx; sipping@xxxxxxxx > Subject: RE: TR: I-D > Action:draft-boucadair-sipping-ipv6-atypes-00.txt > > > Hi Dan, > > Thank you for your comments. > > Please see inline. > > > > -----Message d'origine----- > De : Dan Wing [mailto:dwing@xxxxxxxxx] > Envoyé : jeudi 5 mars 2009 02:29 > À : BOUCADAIR Mohamed RD-CORE-CAE; sipping@xxxxxxxx > Objet : RE: TR: I-D > Action:draft-boucadair-sipping-ipv6-atypes-00.txt > > > Comments are more than welcome. > > Hi. > > This draft appears to describe how SBCs can assist > IPv4-/IPv6-only nodes in communicating with each other by > modifying SDP offers and SDP answers. > > > Med: Not only SBCs, but to assist SIP proxy servers in their > logic of invoking adaptation functions (i.e. NAT64/ALGS) when > heterogeneous (i.e. IPv4 and IPv6) UAs are involved in a > session. If there is an ALG involved, it is presumably modifying the SDP. So, it is performing the same function as an SBC, right? Med: Not only SDP part but also some SIP headers such as contact. I personally don't like to closely relate a function and a node. In the context of v4-v6 interworking an SBC may embed an ALG together with an NAT64 function. > Currently, there is no standardised procedure to > implement this. Agreed. > I presume this is done to avoid doing ICE on the endpoints, > even though draft-ietf-sipping-v6-transition says IPv6 > endpoints SHOULD implement ICE to assist with the IPv6 > transition -- but I'm not sure; the document doesn't discuss > why the atypes is superior to ICE. > > > Med: atypes is not to be positioned vs. ICE or ANAT because > these attributes *** do not solve the same problem ***. > Atypes is a means for proxies to invoke ALGs/NAT64 to prevent > session failure. The support of ANAT/ICE is not sufficient to > guarantee the establishment of a session between heterogeneous UA. draft-wing-behave-nat64-referrals-00.txt shows how referrals work between UAs of different IP address families using NAT64 and using TURN-IPv6 -- using ICE. ICE needs to be on the IPv6 endpoint (it doesn't need to be on the IPv4 endpoint). Med: I have read the draft. ICE support is required. Furthermore, it does not optimise the invocation of NAT64/ALG function. The intermediary PS needs to have "deterministic" information. NAT64 and IPv4-IPv6 ALG function should not for instance be used when a DS is involved in a communication. > I think I understand why the sip.atypes media feature tag is > useful (because the SBC can only really know about the > endpoint's ability to handle signaling, not media). But is > there harm in the SBC assuming the obvious -- namely, that an > incoming IPv4 SIP signaling connection from an endpoint means > the endpoint supports IPv4 media, and that an incoming IPv6 > signaling connection from an endpoint means the the endpoint > supports IPv6 media? > > > Med: This is one of the issues which atypes solves. If you > assume that an UA which issued its signalling messages with > IPv4 is IPv4-only and a remote UA which issued its signalling > messages with IPv6 is IPv6-only, then the intermediary > proxies server will invoke its ALG/NAT64 to adapt the > received SDP offers even if one of the participant may a DS. > atypes avoids also redundant inclusion of ALG/ NAT-PT nodes > in the path, especially in the context of inter-provider > communications. Ok. > draft-boucadair-sipping-ipv6-atypes also uses ANAT > (RFC4091/RFC4092) which has two deficiencies: (a) an ANAT > offer is confusing to SDP receivers that are ANAT-unaware > (because of the multiple m= lines some SIP endpoints > supposedly reject the invitation) and (b) ANAT will be > deprecated when ICE is published. > > > Med: ANAT is only used as an example to illustrate that > several network address types may be embedded in an SDP > offers. The atypes proposal works also with ICE, even if I > personally believe that for this IPv4/IPv6 issues, we don't > need to deploy a heavy machine such as ICE and only the > support of ANAT would be required. But ANAT doesn't work well. And it is being deprecated. If we need some light-weight way of offering both v4 and v6, and want it to be a standard, we need something different. Either lighter weight ICE (e.g., without connectivity checks maybe?) or SDP Capability Negotiation, or something. Med: I definitely vote for something more lightweight than ICE to ease IPv4-IPv6 interworking. atypes does solve some of the IPv4-IPv6 interworking. A NAT64 is involved in the path (by the proxy server) based on the atypes value. But, if we need to have other means to prioritise/promote IPv6, we need something else more lightweight than ICE. -d _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
