Subject: Re: [Sipping] TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Mar 2009 17:29:19 -0800

> 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.  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.  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?

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.

-d

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 07:33:46 +0100

Hi Dan, 

Thank you for your comments.

Please see inline.

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 5 mars 2009 02:29
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Objet : RE: [Sipping] TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt

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. Currently, there is no standardised procedure to implement this.

  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.

 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.

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. 

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 01:36:54 -0500

1) The ICE model fundamentally doesn't work for certain SIP deployment types.  The problem is that in some call scenarios, a UA cannot get usable IP:port candidates which can reach or be reached from another UA.  This was one of the missing pieces of TURN: SBC's don't always assign the UA public IP:ports on the other side of their relay.  They assign IP:ports based on where the SIP call *goes*, which often is in fact a private IP:port pair on the other side of the relay, or a whole *chain* of them.  For example, the call may well go into a VPN/tunnel/LSP/private-net, and it may have even started in another VPN/tunnel/LSP/private-net.  In such cases, the ports allocated for relaying are not knowable in advance of the call routing decision.  What's worse is that they are likely to be overlapping address spaces, or require transcoding, or need to be RHOC'ed, or whatever.

Add on top of that, that the UA's have to support ICE to begin with, which as I'm sure you know is still uncommon.  Draft-ietf-sipping-v6-transition can recommend whatever it wants, but that has no correlation to what may actually occur. (not that the IETF has a bad history of v6-transition plans or anything ;)

So what we're left with is "assisted" v4-v6 interworking, being performed by intermediaries.  In some cases this function is virtually for free, because the intermediary was relaying the media anyway for numerous other reasons; in other cases they want to avoid relaying, or can only do v4-v6 in a subset of intermediaries.  Most SBC's have schemes to release the media (not relay it), if it's possible and their operators want them to, even if it crosses many SBCs; but not all SBC's/intermediaries can do that.

2) Yes SBC's often assume that signaling and media have a common address family for registered endpoints, and that should work in most cases.  The tricky part is how to deal with dual-stack UA's, or when a call gets routed to a proxy, which can then route it on to gateways, media servers or other UA's which themselves may be either IPv4 or IPv6 capable for media.  Today the SBC's typically do one of two things: either (a) assume that signaling and media are the same address family, or (b) offer both address families and wait for the answer to decide which to use, and whether they can release the media or not (if they can release media).  Option (b) is basically similar to how some devices make transcoding decisions today, and is how one would best avoid relaying media.  The problem with (b) is that the UA has to do ANAT, and there's a performance penalty for decomposed system types to do this trick.

So anyway, to accomplish (b), they can either implement ICE, or they can use ANAT.  Honestly neither of them are very good options currently.  ICE support is minimal, and has the problems I noted earlier (plus others).  ANAT has backwards-compatibility issues due to its syntax, or worse call failures if the Require tag is used.  Unfortunately, ANAT has a head-start for v4-v6 and is in fact mandated not only by some SDO's but also by certain US Government organizations.  I think that can be rectified, maybe, but only if an alternative proposed is actually usable in practice.

-hadriel
p.s. I'm not saying this draft's proposal is the right solution - just answering your questions. :)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dan Wing
> Sent: Wednesday, March 04, 2009 8:29 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-
> 00.txt
>
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 02:01:04 -0500

> Of [email-masked]
> Sent: Thursday, March 05, 2009 1:34 AM
>
> Med: ... atypes
> avoids also redundant inclusion of ALG/ NAT-PT nodes in the path,
> especially in the context of inter-provider communications.

Not to disagree with your other points, but this one in particular is not solved by atypes, afaict.  The atypes info is known only to the domain the UA registered with.  When you send a call from your domain to another provider, your proxy won't know the final target UA's atype in advance.

In theory, if you use ANAT then your IBCF/SBC/whatever could keep the original address family as the first ANAT group and insert the alternate address family of the IBGF/SBC/NAT-PT/whatever as the second ANAT group.  That way you're preferring to keep the same IP Address family, but also offering the other one at a lower preference.  That way you can avoid doing v4-v6 unless you really have to.

I agree with you that ICE won't be the answer, but ANAT has some serious issues too, which RFC 4092 does not solve.  I think we may just need to define a new SDP attribute to handle this.

-hadriel

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 08:08:54 +0100

Thanks Hadriel for this clarification.

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Hadriel Kaplan [mailto:[email-masked]] 
Envoyé : jeudi 5 mars 2009 08:01
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]; [email-masked]
Objet : RE: [Sipping] TR: I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]

Med: I assume that interconnection agreements are already in place and the capabilities of the adjacent/interconnection nodes are known to the proxy server. The invocation process of the adaptation functions will be based on that information and the atypes. 

-hadriel

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 5 Mar 2009 06:24:54 -0800

Hadriel,

>1) The ICE model fundamentally doesn't work for certain SIP deployment types.

Could you venture to give an intuitive estimate of the % of cases where ICE does not work?
In the scenarios described here.

Thanks, Henry

On 3/5/09 12:36 AM, "Hadriel Kaplan" <[email-masked]> wrote:

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Mar 2009 09:13:32 -0800

> 1) The ICE model fundamentally doesn't work for certain SIP 
> deployment types.  The problem is that in some call 
> scenarios, a UA cannot get usable IP:port candidates which 
> can reach or be reached from another UA.  This was one of the 
> missing pieces of TURN: SBC's don't always assign the UA 
> public IP:ports on the other side of their relay.  They 
> assign IP:ports based on where the SIP call *goes*, which 
> often is in fact a private IP:port pair on the other side of 
> the relay, or a whole *chain* of them.  For example, the call 
> may well go into a VPN/tunnel/LSP/private-net, and it may 
> have even started in another VPN/tunnel/LSP/private-net.  In 
> such cases, the ports allocated for relaying are not knowable 
> in advance of the call routing decision.  What's worse is 
> that they are likely to be overlapping address spaces, or 
> require transcoding, or need to be RHOC'ed, or whatever.

I agree that ICE uses a 'get addresses, then route the SIP
message' model, whereas SBCs use a 'figure out where the
SIP message is going to be routed, and choose an address
suitable for that destination'.

> Add on top of that, that the UA's have to support ICE to 
> begin with, which as I'm sure you know is still uncommon.

I agree ICE is uncommon with UA's that are deployed with
SBCs, and ICE is uncommon with many IP PBX vendors UAs (Cisco, 
Nortel, Avaya, Siemens, etc.).

ICE is common with SIP UAs deployed elsewhere, though --
Yahoo/MSN Chat/Google Chat all use ICE, for example.

> Draft-ietf-sipping-v6-transition can recommend whatever it 
> wants, but that has no correlation to what may actually 
> occur. (not that the IETF has a bad history of v6-transition 
> plans or anything ;)

Sure.

Draft-ietf-sipping-v6-transition is in the RFC editor's queue 
and I agree it is already out of date.

> So what we're left with is "assisted" v4-v6 interworking, 
> being performed by intermediaries. 

Yes -- either TURN-IPv6 servers, NAT64 devices, or SBCs.
draft-wing-behave-nat64-referrals-00.txt describes the
first two, and I have been considering adding SBCs to it.

That is where I started wondering how much of 
draft-boucadair-sipping-ipv6-atypes is required for an SBC
to perform the v4/v6 interworking.

> In some cases this 
> function is virtually for free, because the intermediary was 
> relaying the media anyway for numerous other reasons; in 
> other cases they want to avoid relaying, or can only do v4-v6 
> in a subset of intermediaries.  Most SBC's have schemes to 
> release the media (not relay it), if it's possible and their 
> operators want them to, even if it crosses many SBCs; but not 
> all SBC's/intermediaries can do that.
> 
> 2) Yes SBC's often assume that signaling and media have a 
> common address family for registered endpoints, and that 
> should work in most cases.  The tricky part is how to deal 
> with dual-stack UA's,

Yes, that is very tricky -- especially when they really
aren't "really" dual stack (e.g., an IPv6-only endpoint 
with access to a NAT64; a dual-stack endpoint with IPv4-only 
Internet connectivity and 6to4 or Teredo).

> or when a call gets routed to a proxy, 
> which can then route it on to gateways, media servers or 
> other UA's which themselves may be either IPv4 or IPv6 
> capable for media.  Today the SBC's typically do one of two 
> things: either (a) assume that signaling and media are the 
> same address family, or (b) offer both address families and 
> wait for the answer to decide which to use, and whether they 
> can release the media or not (if they can release media).  
> Option (b) is basically similar to how some devices make 
> transcoding decisions today, and is how one would best avoid 
> relaying media.  The problem with (b) is that the UA has to 
> do ANAT, and there's a performance penalty for decomposed 
> system types to do this trick.
>
> So anyway, to accomplish (b), they can either implement ICE, 
> or they can use ANAT.

Some day, after SDP Capability Negotiation is published and
becomes available in endpoints, it can be another way of
accomplishing that same result.

> Honestly neither of them are very good 
> options currently.  ICE support is minimal, and has the 
> problems I noted earlier (plus others).  ANAT has 
> backwards-compatibility issues due to its syntax, or worse 
> call failures if the Require tag is used. 

Yep.

> Unfortunately, 
> ANAT has a head-start for v4-v6 and is in fact mandated not 
> only by some SDO's but also by certain US Government 
> organizations. 

Yes.  But that is mostly due to ICE not being an RFC at the
time those standards and requirements were written.  It
wasn't because ANAT is superior.

> I think that can be rectified, maybe,

I worry we are too late to rectify it.

> but 
> only if an alternative proposed is actually usable in practice.

So -- you need a way to do v6/v4 address selection that isn't
ANAT and isn't ICE.

> -hadriel
> p.s. I'm not saying this draft's proposal is the right 
> solution - just answering your questions. :)

draft-boucadair-sipping-ipv6-atypes does seem to solve several
problems.

-d

> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Dan Wing
> > Subject: Re: [Sipping] TR: I-D 
> Action:draft-boucadair-sipping-ipv6-atypes-
> > 00.txt
> >
> > This draft appears to describe how SBCs can assist 
> IPv4-/IPv6-only nodes
> > in
> > draft-ietf-sipping-v6-transition says IPv6 endpoints SHOULD 
> implement ICE
> > to
> > 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
> > signaling connection from an endpoint means the endpoint 
> supports IPv4
> > media,
> > and that an incoming IPv6 signaling connection from an 
> endpoint means the
> > the
> > draft-boucadair-sipping-ipv6-atypes also uses ANAT 
> (RFC4091/RFC4092) which
> > has

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Mar 2009 09:25:43 -0800

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, March 04, 2009 10:34 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sipping] TR: I-D 
> Action:draft-boucadair-sipping-ipv6-atypes-00.txt
> 
> 
> Hi Dan, 
> 
> Objet : RE: [Sipping] TR: I-D 
> Action:draft-boucadair-sipping-ipv6-atypes-00.txt
> 
> 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?

> 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).

> 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.

> (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.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Mar 2009 09:30:08 -0800

> Sent: Wednesday, March 04, 2009 11:09 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Sipping] TR: 
> I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt
> 
> 
> Objet : RE: [Sipping] TR: 
> I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt
> 
> 
> 
> Not to disagree with your other points, but this one in 
> particular is not solved by atypes, afaict.  The atypes info 
> is known only to the domain the UA registered with.  When you 
> send a call from your domain to another provider, your proxy 
> won't know the final target UA's atype in advance.
> 
> 
> Med: I assume that interconnection agreements are already in 
> place and the capabilities of the adjacent/interconnection 
> nodes are known to the proxy server. The invocation process 
> of the adaptation functions will be based on that information 
> and the atypes. 

But that means all users, belonging to another entity, would have
to use the same IP address family.  This prevents a graceful upgrade
from IPv4 to IPv6 as the handsets/SIP UAs/etc. become IPv6-capable,
as there will be unnecessary translation to the old address family
(IPv4) even though IPv6 could be done end-to-end.  

Who would flip that configuration switch on Tuesday at 3am to
declare 'most of my users are IPv6'?  That's risky because it will
now exercise code paths that have never been exercised.

-d

> In theory, if you use ANAT then your IBCF/SBC/whatever could 
> keep the original address family as the first ANAT group and 
> insert the alternate address family of the 
> IBGF/SBC/NAT-PT/whatever as the second ANAT group.  That way 
> you're preferring to keep the same IP Address family, but 
> also offering the other one at a lower preference.  That way 
> you can avoid doing v4-v6 unless you really have to.
> 
> I agree with you that ICE won't be the answer, but ANAT has 
> some serious issues too, which RFC 4092 does not solve.  I 
> think we may just need to define a new SDP attribute to handle this.
> 
> -hadriel

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 19:05:19 +0100

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 5 mars 2009 18:26
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Objet : RE: [Sipping] TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt

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.

Agreed.

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. 

Ok.

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

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 19:13:23 +0100

See inline.

Cheers
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 5 mars 2009 18:30
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]; [email-masked]
Objet : RE: [Sipping] TR: I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt

> De : Hadriel Kaplan [mailto:[email-masked]] Envoyé : jeudi 5 
> mars 2009 08:01 À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]; 
> [email-masked] Objet : RE: [Sipping] TR:
> Not to disagree with your other points, but this one in particular is 
> not solved by atypes, afaict.  The atypes info is known only to the 
> domain the UA registered with.  When you send a call from your domain 
> to another provider, your proxy won't know the final target UA's atype 
> in advance.
> 
> 
> Med: I assume that interconnection agreements are already in place and 
> the capabilities of the adjacent/interconnection nodes are known to 
> the proxy server. The invocation process of the adaptation functions 
> will be based on that information and the atypes.

But that means all users, belonging to another entity, would have to use the same IP address family.  This prevents a graceful upgrade from IPv4 to IPv6 as the handsets/SIP UAs/etc. become IPv6-capable, as there will be unnecessary translation to the old address family
(IPv4) even though IPv6 could be done end-to-end.  

Med: I don't get the point Dan.

Who would flip that configuration switch on Tuesday at 3am to declare 'most of my users are IPv6'?  That's risky because it will now exercise code paths that have never been exercised.

-d

> In theory, if you use ANAT then your IBCF/SBC/whatever could keep the 
> original address family as the first ANAT group and insert the 
> alternate address family of the IBGF/SBC/NAT-PT/whatever as the second 
> ANAT group.  That way you're preferring to keep the same IP Address 
> family, but also offering the other one at a lower preference.  That 
> way you can avoid doing v4-v6 unless you really have to.
> 
> I agree with you that ICE won't be the answer, but ANAT has some 
> serious issues too, which RFC 4092 does not solve.  I think we may 
> just need to define a new SDP attribute to handle this.
> 
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 15:49:57 -0500

________________________________________
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Thursday, March 05, 2009 9:25 AM
> To: Hadriel Kaplan; Dan Wing; [email-masked]; [email-masked]
> Subject: Re: [Sipping] TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt
>

Nope, I have no idea what the % is, because we don't track that separately.  It's a lot more than one would think though, because essentially SIP peering and SIP-Trunks work that way.  Your call started from your house or Enterprise, into a Service Provider, and from there if the call gets routed to a peering partner, the media relay path setup would go through the access SBC's between you and the provider, and then through the peering SBC's into the next provider, and so on. Or the SIP call started on a Mobile Switch, CO switch, or PSTN gateway, and if it gets routed out of the PoP or domain to another provider or for example for international termination, the media gets relayed through the peering SBCs to specific peering trunks.

Or if you make an E911 call, the PSAP distributor has its own SBC's, which relay the media for the specific calls that get routed to it, but sometimes release the media when they then get routed to specific PSAPs.  And of course if your call is lawfully intercepted, it gets relayed.  And I know that being able to bridge calls between Enterprise VPN's is a popular feature, because we used to win deals over competitors who couldn't do that.  And I know of operators that have MPLS-TE LSPs between SBC's for voice traffic, to do shortcut routing and/or fast-reroute protection.

And a lot of providers' PSTN gateways for inbound/outbound calls and voicemail systems are in a private network, and they don't do ICE, so the only way to get your media into that private network is by relaying it, but if the call ends up going to another SIP subscriber it may get released.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 11:17:22 -0700

> Sent: Thursday, March 05, 2009 10:05 AM
> 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.
> 
> 
> Med: I have read the draft. ICE support is required. 

Yes, that is because SIP and SIPPING documents all require ICE
for IPv4/IPv6 interworking.  Your document is a departure from
requiring ICE, and puts the onus on the SBC to perform the
interworking.  I'm not saying that is wrong; rather, it is
different.

> 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. 
> 
> 
> 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.

I agree that atypes proposes a different solution which is
more lightweight for the SIP UAs.  However, it does require the
SIP UAs depend on the SBC to work in a different address 
family.  In some environments, where there is always an SBC
involved with the call, that is probably a reasonable 
requirement and atypes would be a good solution in those
networks -- similarly, perhaps on those networks one can
assume support for Grouping.

But for the rest of the Internet, where those assumptions 
cannot be made, I do like the *idea* of atypes, but I would
suggest some changes to it (e.g., don't use multiple m-lines
because they cause harm.  e.g., provide a way to detect if
a IPv4 or IPv6 path is working -- as we all know with the
difficulties in keeping www.ietf.org working over IPv6,
IPv6 connectivity is not yet as reliable as IPv4 connectivity.)

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 11:20:14 -0700

> Sent: Thursday, March 05, 2009 10:13 AM
> To: [email-masked]; [email-masked]; [email-masked]
> [mailto:[email-masked]] On 
> particular is 
> But that means all users, belonging to another entity, would 
> have to use the same IP address family.  This prevents a 
> graceful upgrade from IPv4 to IPv6 as the handsets/SIP 
> UAs/etc. become IPv6-capable, as there will be unnecessary 
> translation to the old address family

Let me explain my point.  If I am operating a network that is 100% IPv4,
how do I indicate to other networks that some of my users
now support IPv6?  That is, if the other service provider
is doing that adaptation function, how does the adaptation function get 
involked for my some of my users that support IPv6?

-d

> declare 'most of my users are IPv6'?  That's risky because it 
> will now exercise code paths that have never been exercised.
> 
> -d
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 9 Mar 2009 23:23:50 -0400

> Sent: Monday, March 09, 2009 2:17 PM
> 

I don't believe all SIP/SIPPING docs require ICE for IPv4/IPv6.  There are two current RFC's for ANAT, which are not deprecated (yet).  I know and you know it's broken, but the alternative for some of us is that media will simply always be the same address family as signaling. (which is not optimal, and it doesn't have to be that way - we can fix it methinks)

> cannot be made, I do like the *idea* of atypes, 

I'm not sure the idea of atypes is necessary or sufficient to solve the problem.  We need a form of ANAT which works with legacy devices cleanly.

> but I would
> because they cause harm. 

Yes I agree with that requirement a lot.

> e.g., provide a way to detect if

It turns out we have a means of detecting that already: the human will hang up if they don't hear anything.  But more seriously, it's not like you need ICE to detect which one is working either.  You can use RTCP, for example.

It would be one thing if ICE was universally usable, but it's not.  Not for many of us.  We can't force all UA's to implement it, and many haven't; and it doesn't work for some scenarios some people need.

The IETF has never succeeded in *dictating* market forces.  We can either stick our heads in the sand and claim our engineering principles require us to follow a specific model we believe is right, or we can be real engineers and incorporate customer feedback and real-world limitations into pragmatic solutions.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 20:43:59 -0700

> I don't believe all SIP/SIPPING docs require ICE for 
> IPv4/IPv6. 

I am only familiar with draft-ietf-sipping-v6-transition (which
requires ICE) and Section 6.2 of draft-ietf-sipping-nat-scenarios 
which has the IPv6 host go through a NAT (a NAT64, I believe) to
obtain an IPv4 address for media from a TURN server.

If there are other SIP or SIPPING documents which describe the
IPv4/IPv6 transition, please share.

> There are two current RFC's for ANAT, which are 
> not deprecated (yet).  I know and you know it's broken, but 
> the alternative for some of us is that media will simply 
> always be the same address family as signaling. (which is not 
> optimal, and it doesn't have to be that way - we can fix it methinks)
>
> I'm not sure the idea of atypes is necessary or sufficient to 
> solve the problem.  We need a form of ANAT which works with 
> legacy devices cleanly.

Agreed.  An in that regard it would be something more akin to
ICE or SDP Capability Negotiation (which both work with
legacy devices cleanly because they use SDP "a=" and are
designed to fall back cleanly).

> It turns out we have a means of detecting that already: the 
> human will hang up if they don't hear anything.  But more 
> seriously, it's not like you need ICE to detect which one is 
> working either.  You can use RTCP, for example.

RTCP isn't sent too often or reliably, though (how is a=rtcp and 
even/odd port support working out in practice?).

You can probably more likely expect to receive either RTP _or_ RTCP
pretty soon after it feels like the call is 'established',
though -- very much like the 'latching' described in the
Middlebox document (draft-sipping-stucker-media-path-middleboxes).

And the user reaction to installing IPv6 and suddenly receiving
(or initiating) phone calls with no audio is going to be blamed
squarely on IPv6.  That is not appealing for the successful
deployment of IPv6.  Here is the conversation which we all 
know would occur:

  Bob, I just tried to call you and got no audio.

  Adam, I'm sorry.  I recently installed IPv6.

  Bob, All my friends that installed IPv6 have that problem.  
       IPv6 causes one-way audio.  Can you remove it so we
       can use SIP?

  Adam, Sure thing!

> It would be one thing if ICE was universally usable, but it's 
> not.  Not for many of us.  We can't force all UA's to 
> implement it, and many haven't; and it doesn't work for some 
> scenarios some people need.

Contrary to everyone's hopes and desires, IPv6 endpoints are not
universally deployed.  So getting v6 endpoints to include 
features that are necessary for a successful IPv4/IPv6 transition
is exactly aligned with the the needs of vendors implementing
IPv6 endpoints.

Of course, if they just grin and expect the SBC solves the 
problem, we can all sleep easier at night.  Well, except
SBC vendors, I guess?

> The IETF has never succeeded in *dictating* market forces.  
> We can either stick our heads in the sand and claim our 
> engineering principles require us to follow a specific model 
> we believe is right, or we can be real engineers and 
> incorporate customer feedback and real-world limitations into 
> pragmatic solutions.

<cough>NAT</cough>.  :-)

-d

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 09 Mar 2009 21:13:59 -0700

Frankly, I think using ICE has more changes of working than the
alternatives.

Go ahead and try to use ANAT with a device that supports both Audio and
Video. It makes a pretty horrible SDP.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Mar 2009 00:32:18 -0400

> From: Dan Wing [mailto:[email-masked]]
> Sent: Monday, March 09, 2009 11:44 PM
> 

Oh, I didn't know we had to have a separate RFC X to state how to use another RFC Y, and that without X there was no way to use Y.
Should we have an sdp-cap-neg-transition document too?  ;)

> even/odd port support working out in practice?).

My comment was a trap actually: if you argue RTCP can't be used for such a check because it isn't supported too often, I can turn that argument around on ICE very easily.  In fact I'd wager there're more devices doing RTCP than ICE, by a big margin.
(How is a=candidate working out in practice? :)

[BTW, a=rtcp is broken and should be deprecated, as you know, but you don't need it to use RTCP obviously]

> is exactly aligned with the the needs of vendors implementing

Sure, we need to put the burden of interworking with IPv4 legacy devices squarely on the shoulders of IPv6, no doubt. (whether it'll be solely handled by IPv6 endpoints in all cases is debatable, but that's orthogonal)  

But I fail to see how ICE is necessary or sufficient to fit that bill.  Either way, we need to provide IPv6 devices with as *many* tools as possible, so that your failed-session example does not occur.

> problem, we can all sleep easier at night. 

I didn't say that, and I don't even believe it.  There are many SIP domains which have no SBC's, and shouldn't.  For them, ICE is great.  For others, not so much.  We should let the two communicate.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Mar 2009 00:36:16 -0400

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, March 10, 2009 12:14 AM
> 

I'm not arguing ANAT is an answer - it isn't, imo.  It doesn't work with legacy IPv4 devices, due to its syntax.  We can change the syntax.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 9 Mar 2009 21:54:38 -0700

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Monday, March 09, 2009 9:32 PM
> To: Dan Wing; [email-masked]; [email-masked]
> Subject: Re: [Sipping] TR: 
> Oh, I didn't know we had to have a separate RFC X to state 
> how to use another RFC Y, and that without X there was no way 
> to use Y.

If we need one, sure.

Recall the original plan for v6 was 'just install it, and
everything works'.  That failed.  The industry has figured
that out, and IETF is trying to do its part to correct that
failure.

> My comment was a trap actually: if you argue RTCP can't be 
> used for such a check because it isn't supported too often, I 
> can turn that argument around on ICE very easily.  In fact 
> I'd wager there're more devices doing RTCP than ICE, by a big margin.

Not well.  But a=candidate has semantics.  a=rtcp in an answer
doesn't indicate an RTCP is going to be sent soon or immediately.

> [BTW, a=rtcp is broken and should be deprecated, as you know, 
> but you don't need it to use RTCP obviously]

RTP/RTCP multiplexing is what all the cool kids do in 2009.

> Sure, we need to put the burden of interworking with IPv4 
> legacy devices squarely on the shoulders of IPv6, no doubt. 
> (whether it'll be solely handled by IPv6 endpoints in all 
> cases is debatable, but that's orthogonal)  
> 
> But I fail to see how ICE is necessary or sufficient to fit 
> that bill.  Either way, we need to provide IPv6 devices with 
> as *many* tools as possible, so that your failed-session 
> example does not occur.

I acknowledge that SIP / SIPPING have not had a discussion
of how to best accomplish the v4/v6 transition, especially
in light of the failure of dual-stack hosts and in light
of the emergence of IPv6+NAT44 ("dual-stack lite") and 
NAT64.  These are all relatively 'new', of course, but we
are somewhat running out of time to navel gaze.  V4 addresses
continue to be used up, even "due to this economic climate" 
(I mention that solely because I'm sure someone would tell 
me that the consumption of IPv4 addresses has slowed "due
to the current economic climate").

> I didn't say that, and I don't even believe it.  There are 
> many SIP domains which have no SBC's, and shouldn't.  For 
> them, ICE is great.  For others, not so much.  We should let 
> the two communicate.

Yes, we need the two to communicate.

It sounds a lunch or bar-BoF is in order?

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 10 Mar 2009 01:08:47 -0400

> Sent: Tuesday, March 10, 2009 12:55 AM
> To: Hadriel Kaplan; [email-masked]; [email-masked]
> 

Actually I think we're like 0 for 3 or something so far.

> It sounds a lunch or bar-BoF is in order?

Yeah.  First round's on me, unless it's a ton of folks - due to the current economic climate. ;)

-hadriel

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 07:41:36 +0100

Hi Dan,

Please see inline.

Cheers
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : lundi 9 mars 2009 19:17
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Objet : RE: [Sipping] TR: I-D Action:draft-boucadair-sipping-ipv6-atypes-00.txt

I agree that atypes proposes a different solution which is
more lightweight for the SIP UAs.  

Med: Yes.

However, it does require the
SIP UAs depend on the SBC to work in a different address 
family.  

Med: SBC is not mandatory. But I understand you are referring to an intermediary server (e.g. proxy server). Then, the answer is yes.

In some environments, where there is always an SBC

Med: Ok.

Med: In fact, the ***only*** scenario which requires the support of ANAT (or multiple media line) is when a DS is the initiator of the call. For this scenario, I suggest the following: DS UA issues its INVITE with a atypes set to "ipv4,ipv6" and an empty SDP. When the request is received by the proxy server or by the remote UA, then it uses atypes is used to determine which offer to enclose in its SDP offer part of 200 OK message. 

But, I admit that I'm in favour of simplifying the ANAT syntax than using this "empty SDP".

-d

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 07:51:29 +0100

Please see inline

Cheers
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : lundi 9 mars 2009 19:20
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]; [email-masked]
Objet : RE: [Sipping] TR: I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt

> 
> But that means all users, belonging to another entity, would have to 
> use the same IP address family.  This prevents a graceful upgrade from 
> IPv4 to IPv6 as the handsets/SIP UAs/etc. become IPv6-capable, as 
> there will be unnecessary translation to the old address family

Med: If your network is 100% IPv4 and all communications should cross your realm, there is no chance to let you IPv6-enabled customers to use IPv6 capabilities to access the service !

how do I indicate to other networks that some of my users now support IPv6?

Med: This question is valid only when IPv6 is handled in your domain (e.g. correct parsing of IPv6 addresses, accept to enclose IPv6 addresses in SIP messages, etc.). My proposal is as follows:

- SIP interconnection agreement between two IP telephony administrative domains should include a technical clause which refers to this IPv6 capability and that atypes is part of the "SIP profile" (i.e. accepted header when entering the adjacent domain).
- When atypes is set in a message issued by a UA, the proxy server of the originating domain retrieves next hop, which is in this interconnection scenario the interconnection node or the adjacent Proxy Server. The forwarded request must keep the atypes.
- The request is then received by the adjacent proxy server. It uses the atypes value of the INVITE together with the ones stored in its registration db to determine if NAT-PT/NAT64/NAT46/SIP-ALG is required.

  That is, if the other service provider is doing that adaptation function, how does the adaptation function get involked for my some of my users that support IPv6?

Med: This is driven by the (atypes of source, atypes of destination). Did I answered your question?

-d

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 08:09:12 +0100

-----Message d'origine-----
De : Hadriel Kaplan [mailto:[email-masked]] 
Envoyé : mardi 10 mars 2009 04:24
À : Dan Wing; BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Objet : RE: [Sipping] TR: I-DAction:draft-boucadair-sipping-ipv6-atypes-00.txt

> Behalf Of Dan Wing
> Yes, that is because SIP and SIPPING documents all require ICE for 
> IPv4/IPv6 interworking.  Your document is a departure from requiring 
> ICE, and puts the onus on the SBC to perform the interworking.  I'm 
> not saying that is wrong; rather, it is different.

> But for the rest of the Internet, where those assumptions cannot be 
> made, I do like the *idea* of atypes,

> but I would
> suggest some changes to it (e.g., don't use multiple m-lines because 
> they cause harm.

Med: I think that we agree that for optimisation purposes, we need to encloses several IP address types in the SDP part. ANAT is a good candidate than ICE. We can start from there, if there is a consensus, to propose a more simplified syntax.