Subject: [Sipping] SIP IPv6 Transition: ICE or ANAT

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 19 Mar 2007 19:01:10 +0100

Folks,

today in the MMUSIC session, the ICE draft was presented. One of the 
open issues relates to the SIP IPv6 Transition draft, which is a SIPPING 
document that will be IETF LCed shortly.

The open issue is whether to use only ICE for SIP IPv6 transition and 
deprecate ANAT, or to do something else (e.g., ICE + ANAT). For more 
information, see Jonathan's ICE slides in MMUSIC.

The group asked for more time to think about this issue. It was decided 
to make this decision in the SIPPING session on Friday (*and not 
later*). So, if you have an opinion, please send a note to this 
(SIPPING) mailing list.

Thanks,

Gonzalo
SIPPING co-chair

_______________________________________________
Sipping mailing list  https://www1.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: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 20 Mar 2007 01:00:20 +0100

By all means help in making the decisions by discussing the issue in SIPPING, and the contents of the IPv6 transition draft of course belongs to SIPPING.

However the RFCs associated with ANAT belong to MMUSIC and SIP WG respectively, and therefore any decision on the status of these documents must be made by these WG.

Regards

Keith

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 6:01 PM
> To: sipping
> Cc: Gurbani, Vijay K (Vijay); Mary Barnes; Karim El Malki
> Subject: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> Folks,
> 
> today in the MMUSIC session, the ICE draft was presented. One 
> of the open issues relates to the SIP IPv6 Transition draft, 
> which is a SIPPING document that will be IETF LCed shortly.
> 
> The open issue is whether to use only ICE for SIP IPv6 
> transition and deprecate ANAT, or to do something else (e.g., 
> ICE + ANAT). For more information, see Jonathan's ICE slides 
> in MMUSIC.
> 
> The group asked for more time to think about this issue. It 
> was decided to make this decision in the SIPPING session on 
> Friday (*and not later*). So, if you have an opinion, please 
> send a note to this
> (SIPPING) mailing list.
> 
> Thanks,
> 
> Gonzalo
> SIPPING co-chair
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 01:05:57 -0500

Sign me up for both ICE and ANAT.

I know a lot of work has gone into ICE, and there's various ways to
implement it, but it simply is far too intricate for many wireless
devices to likely be able to support for some time. 

If all you're wanting to do is simply group the addresses for different
IP versions together in SDP, with no desire or need to perform all of
the candidate checking/selection logic, then ICE seems like it's
overkill for this job and ANAT is sufficient. However, if folks want to
use ICE in conjunction with NAT traversal while transititioning to an
IPv6 network, there doesn't seem to me to be a reason to say no to that.

There's no reason that springs to mind as to why you would use ANAT if
you're using ICE, but there's also no reason to push all of the added
complexity of ICE onto endpoints that really only need a mechanism to
group some alternative addresses in the SDP either. ANAT without ICE
should be allowed. ICE with ANAT should be disallowed.

Regards,
Brian

> Sent: Monday, March 19, 2007 1:01 PM
> To: sipping
> Cc: Vijay K. Gurbani; Barnes, Mary (RICH2:AR00); Karim El Malki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2007 04:01:39 -0400

cc'ing MMUSIC.

It was my impression that this wasn't going to be 'sipping decides to do 
ANAT or ICE', but rather, 'MMUSIC is asking to steal a 10m block of 
SIPPING for a hum vote on ANAT or ICE'.

To that extent - can I formally have agenda time for this in sipping? It 
needs to be earlier in the agenda since I'm leaving for the airport 
before the session ends.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Mar 2007 09:53:26 +0100

Hi,

my plan was to give you 10 minutes at the beginning of the session to 
present this. Let me know if that works for you.

It would be great if the MMUSIC chairs were there as well in order to 
judge the consensus we may get.

Cheers,

Gonzalo

Jonathan Rosenberg wrote:
>> By all means help in making the decisions by discussing the issue in 
>> SIPPING, and the contents of the IPv6 transition draft of course 
>> belongs to SIPPING.
>>
>> However the RFCs associated with ANAT belong to MMUSIC and SIP WG 
>> respectively, and therefore any decision on the status of these 
>> documents must be made by these WG.
>>
>> Regards
>>
>> Keith
>>
>>
>>> From: Gonzalo Camarillo [mailto:[email-masked]] Sent: 
>>> Monday, March 19, 2007 6:01 PM
>>> To: sipping
>>> open issues relates to the SIP IPv6 Transition draft, which is a 
>>> SIPPING document that will be IETF LCed shortly.
>>>
>>> The group asked for more time to think about this issue. It was 
>>> decided to make this decision in the SIPPING session on Friday (*and 
>>> not later*). So, if you have an opinion, please send a note to this
>>> (SIPPING) mailing list.
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>> SIPPING co-chair
>>>
>>> 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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 21 Mar 2007 10:17:11 +0100

Hi,

I pretty much share Brian's concerns.

We also have the issue with gates etc not passing ICE messages (before a
certain point, or at all). Maybe that will be solved one day, but we are
not there yet.

Regards,

Christer

> From: Brian Stucker [mailto:[email-masked]] 
> Sent: 21. maaliskuuta 2007 8:06
> To: Gonzalo Camarillo (JO/LMF); sipping
> Cc: [email-masked]; Vijay K. Gurbani; Mary Barnes; 
> Karim El Malki
> Subject: RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> I know a lot of work has gone into ICE, and there's various 
> ways to implement it, but it simply is far too intricate for 
> many wireless devices to likely be able to support for some time. 
> 
> If all you're wanting to do is simply group the addresses for 
> different IP versions together in SDP, with no desire or need 
> to perform all of the candidate checking/selection logic, 
> then ICE seems like it's overkill for this job and ANAT is 
> sufficient. However, if folks want to use ICE in conjunction 
> with NAT traversal while transititioning to an
> There's no reason that springs to mind as to why you would 
> use ANAT if you're using ICE, but there's also no reason to 
> push all of the added complexity of ICE onto endpoints that 
> really only need a mechanism to group some alternative 
> addresses in the SDP either. ANAT without ICE should be 
> allowed. ICE with ANAT should be disallowed.
> 
> Regards,
> Brian
>  
> 
> transition and

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 21 Mar 2007 06:17:55 -0400

I agree and think there are additional reasons for not mandating ICE as 
the v4/v6 negotiation mechanism.

As I mentioned in the MMUSIC session, SDP is about indicating a set of 
parameters you support and the other side can then look at those 
parameters and choose to use one or more of those. ICE on the other hand 
is about verifying that one or more transport address alternatives can 
actually be used in practice by exchanging STUN messages with the peer. 
These are two fundamentally different functions, and requiring support 
of the latter to negotiate the former seems like a tall order, no matter 
how much you may believe in ICE.

A couple of other reasons for keeping to just indicating things in SDP 
(without requiring ICE):
- Should have a consistent way of doing this across protocols, whether 
for SIP or not. Would we mandate ICE support for RTSP for example ? What 
about inter-working with other non-IETF protocols ? Clearly, signaling 
inter-working would be required but should we always require media 
interworking as well ? Use of ICE/STUN would effectively impose that.
- We can indicate use of IPv4 without ICE. We can indicate use of IPv6 
without ICE. However, if we want  to indicate use of either of them, we 
all of a sudden need ICE. Clearly, we are in capability negotiation 
land, and ICE is not about capability negotiation (nor should it be). 
You may of course want to verify that the address you select has 
connectivity, but per the above, that is a separate problem.

In short, I'm not in favor of mandating, ICE here, but, as you may have 
guessed, I don't think ANAT is the right long-term answer either (SDP 
capability negotiation with a transport protocol extension would be).

-- Flemming

Christer Holmberg (JO/LMF) wrote:
>>> today in the MMUSIC session, the ICE draft was presented. 
>>>       
>> One of the 
>>     
>>> deprecate ANAT, or to do something else (e.g., ICE + ANAT). 
>>>       
>> For more 
>>     
>>> decided to make this decision in the SIPPING session on 
>>>       
>> Friday (*and 
>>

---

From: Aki Niemi <[email-masked]>
Date: Wed, 21 Mar 2007 11:35:43 +0100

> devices to likely be able to support for some time. 

I have to disagree here. Can you be more elaborate on what aspects of
ICE you find too heavy for mobile devices?

As a data point, the Nokia Internet Tablet already supports ICE, albeit
an old version of it.

> IPv6 network, there doesn't seem to me to be a reason to say no to that.

Sure if your mobile device only ever attaches to this utopian network
where there are no NATs and no firewalls, as well as having no risk ever
getting hit by a voice hammer attack, then yes, ANAT is enough.

> should be allowed. ICE with ANAT should be disallowed.

I would actually seriously entertain the idea of deprecating ANAT. There
may be short term pain associated with implementing ICE, but if in
addition to that you have devices in the end that do both or just ANAT
(because we told them so), interop will suffer.

Cheers,
Aki

---

From: Karim El Malki <[email-masked]>
Date: Wed, 21 Mar 2007 14:23:24 +0100

I'd argue for having both and that they should work together (i.e. ANAT
specifies the alternative addresses and ICE does the connectivity
checks on the alternative addresses and picks the right candidates).
This allows a device to optionally disable ICE (i.e. avoid additional
messages and roundtrips) on IPv6 addresses for example, while still
maintaining the functionality on IPv4 private addresses due to NATs.
I believe this would solve the issues mentioned below by Aki.
It would seem odd (or even counterproductive) to mandate a
NAT-traversal mechanism on IPv6 where the effort has been to
remove NATs.
Karim

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 09:46:26 -0500

> From: Aki Niemi [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 5:36 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Gonzalo Camarillo; sipping; [email-masked]; Vijay 
> K. Gurbani; Barnes, Mary (RICH2:AR00); Karim El Malki
> Subject: Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> 
> ext Brian Stucker wrote:
> I have to disagree here. Can you be more elaborate on what 
> aspects of ICE you find too heavy for mobile devices?

There are many devices that don't even support getting different tags
for forking. I think it's reasonable to expect that asking them to
support a mechanism as complex as ICE, which has had several tutorials
and an insert into the registration packets to explain how it works is
probably too much to ask.

Doesn't mean that it won't ever be supported (although the number of
STUN exchanges can *potentially* add to call setup delay issues), just
that it's really not necessary to solve the IPv4/IPv6 transition issues
which is handled by two 5 page RFCs (i.e. ANAT).

> 
> As a data point, the Nokia Internet Tablet already supports 
> ICE, albeit an old version of it.

That's good to know. How many of your consumer handsets support it?

> > different IP versions together in SDP, with no desire or need to 
> > perform all of the candidate checking/selection logic, then 
> ICE seems 
> > like it's overkill for this job and ANAT is sufficient. However, if 
> > folks want to use ICE in conjunction with NAT traversal while 
> > transititioning to an
> Sure if your mobile device only ever attaches to this utopian 
> network where there are no NATs and no firewalls, as well as 
> having no risk ever getting hit by a voice hammer attack, 
> then yes, ANAT is enough.

Utopian? Hardly. 

There's entire frameworks already specified in IMS (take a look at
TS29.203, 29.212, 29.213, and 29.214) that can more than handle the
voice hammer attack as a result of IP flow gating procedures operators
are interested in using to prevent fraud.

As for NATs and firewalls, again, they exist, and at last check, many
SIP calls are completed every day. ICE is definitely useful, but is not
necessary to solve the problem at hand, which is the IPv4/IPv6
transition. These are separate issues in many networks.

If you take a look at the IMS network architecture, you'll note that the
IP packets from a GGSN going to the P-CSCF are in a private network.
It's reasonable to expect that many mobile-to-mobile VoIP calls can
complete without having problems with NAT and firewall traversal without
ICE. I know of several such networks being developed today.

> use ANAT if 
> I would actually seriously entertain the idea of deprecating 
> ANAT. There may be short term pain associated with 
> implementing ICE, but if in addition to that you have devices 
> in the end that do both or just ANAT (because we told them 
> so), interop will suffer.

I'm not arguing that ANAT might eventually be deprecated, but I want to
deprecate it for the right thing. As Flemming pointed out, there are
larger SDP negotiation issues that should be considered. Additionally, I
think it would be valuable to allow ICE to be deployed more widely
before we declare victory on this issue and deprecate ANAT. I just think
we're jumping the gun here quite a bit.

Cheers.
Brian

---

From: "Mahendran, AC" <[email-masked]>
Date: Wed, 21 Mar 2007 08:09:58 -0700

I have similar concerns as Brian. In addition to the increased
complexity of implementation, ICE also increases the post-dial delay due
to the STUN connectivity checks. I think it is too early to talk about
deprecating ANAT. I am more comfortable with ICE+ANAT.

-AC 

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Wednesday, March 21, 2007 7:06 AM
To: Gonzalo Camarillo; sipping
Cc: Mahendran, AC; Vijay K. Gurbani; Mary Barnes; Karim El Malki
Subject: RE: [Sipping] SIP IPv6 Transition: ICE or ANAT

Regards,
Brian

---

From: Aki Niemi <[email-masked]>
Date: Wed, 21 Mar 2007 16:40:51 +0100

Inline.

> probably too much to ask.

And I'm sure if the implementation effort becomes too big, there will be
open source implementations to at least test against, and maybe also use
directly. Doesn't seem too different to other Internet protocols out there.

> which is handled by two 5 page RFCs (i.e. ANAT).

If you could ever address the traversal issues in isolation, then this
would of course make perfect sense. Unfortunately, I think they cannot,
and as a consequence, it's hard to escape the complexity required to
make things work reliably.

> That's good to know. How many of your consumer handsets support it?

That's not the point. You were arguing that ICE is too heavy for mobile
handsets; I have pointed out that there is already existence proof that
ICE can be done on a mobile device. It's not that big of a deal, really.

> are interested in using to prevent fraud.

I stand corrected. You're right there's plenty of specifications out
there, so it can't be utopian. ;)

> transition. These are separate issues in many networks.

Here we clearly disagree.

> ICE. I know of several such networks being developed today.

You say "many", but not "all". Without using ICE, how are you going to
detect whether the call will work? Is this some trial-and-error style thing?

And last time I checked, a mobile network in Finland gives out *public*
IPv4 addresses, but they are all firewalled. Without hole-punching, your
media for the first couple of seconds will get cut. That's unacceptable.

> we're jumping the gun here quite a bit.

And I think we would be simply delaying the inevitable.

Cheers,
Aki

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 11:28:18 -0500

> aspects of 
> And I'm sure if the implementation effort becomes too big, 
> there will be open source implementations to at least test 
> against, and maybe also use directly. Doesn't seem too 
> different to other Internet protocols out there.

Sure. I'm not saying DON'T implement ICE. I'm saying don't force it down
everyone's throats. Give folks a chance to go off and do this work, see
how it behaves, make any tweaks necessary, and let things take their
natural course. What's so unreasonable about that?

> > that it's really not necessary to solve the IPv4/IPv6 transition 
> > issues which is handled by two 5 page RFCs (i.e. ANAT).
> 
> If you could ever address the traversal issues in isolation, 
> then this would of course make perfect sense. Unfortunately, 
> I think they cannot, and as a consequence, it's hard to 
> escape the complexity required to make things work reliably.

I'm not talking about traversal issues. I'm talking about IPv4/IPv6
transition where you have a device that has multiple interfaces and
needs to bundle those addresses together in an SDP exchange.

> 
> >> As a data point, the Nokia Internet Tablet already supports ICE, 
> >> albeit an old version of it.
> > 
> That's not the point. You were arguing that ICE is too heavy 
> for mobile handsets; I have pointed out that there is already 
> existence proof that ICE can be done on a mobile device. It's 
> not that big of a deal, really.

No, I wasn't. I wasn't arguing anything. I'm stating a fact that many
devices have a hard enough time today with getting all the other many,
many, pieces and parts of SIP, not to mention IMS, working, and that you
don't have to have ICE to handle *IPv4/IPv6 transitional networks*.

> >> where there are no NATs and no firewalls, as well as 
> having no risk 
> >> ever getting hit by a voice hammer attack, then yes, ANAT 
> is enough.
> > 
> > Utopian? Hardly. 
> > 
> I stand corrected. You're right there's plenty of 
> specifications out there, so it can't be utopian. ;)

There's plenty of working implementations of those specifications too.
Again, look at what's out there in the marketplace. Sure, there's a case
to be made for the scenarios you mention, but just because you have SIP
in your network doesn't mean you have equal exposure to those scenarios.
There's more to it than that.

> > SIP calls are completed every day. ICE is definitely useful, but is 
> > not necessary to solve the problem at hand, which is the IPv4/IPv6 

I guess we'll have to agree to disagree.

> 
> > If you take a look at the IMS network architecture, you'll 
> note that 
> > the IP packets from a GGSN going to the P-CSCF are in a 
> private network.
> > complete without having problems with NAT and firewall traversal 
> > without ICE. I know of several such networks being developed today.
> 
> You say "many", but not "all". Without using ICE, how are you 
> going to detect whether the call will work? Is this some 
> trial-and-error style thing?
> 
> IPv4 addresses, but they are all firewalled. Without 
> hole-punching, your media for the first couple of seconds 
> will get cut. That's unacceptable.

Sure. It's not all, but you were making statements to the effect that
nothing could work without ICE, and that's not the case or ICE would
have been specified long ago as part of RFC-3261. Once again, I'm not
arguing against the utility of ICE in any way shape or form. I'm simply
stating that you can handle this specific case with either ANAT or ICE
and that there are good reasons for allowing some flexibility until
people have a chance to deploy ICE more widely into their networks.

Give people some time man.

> 
> >> I would actually seriously entertain the idea of deprecating ANAT. 
> >> There may be short term pain associated with implementing 
> ICE, but if 
> >> in addition to that you have devices in the end that do 
> both or just 
> >> ANAT (because we told them so), interop will suffer.
> > 
> > I'm not arguing that ANAT might eventually be deprecated, 
> but I want 
> > to deprecate it for the right thing. As Flemming pointed out, there 
> > are larger SDP negotiation issues that should be considered. 
> > Additionally, I think it would be valuable to allow ICE to 
> be deployed 
> > more widely before we declare victory on this issue and deprecate 
> > ANAT. I just think we're jumping the gun here quite a bit.
>

---

From: Aki Niemi <[email-masked]>
Date: Wed, 21 Mar 2007 18:02:02 +0100

> needs to bundle those addresses together in an SDP exchange.

Sorry, there was a typo; s/traversal/transition.

But continuing on the same vein, I did some experimentation with IPv6
here in the IETF meeting. Round-trip times for v6 were about twice as
long as for v4 (120ms vs. 60ms). (Aside: my very first experiment failed
since IPv6 routing to my own domain was looping somewhere in transit. Nice.)

I'm sure things will improve, but if you always assume IPv6 is "better"
than IPv4 (latency- or otherwise) you may be disappointed, which in
practice means worse than optimal quality, or worse yet, a dead call. I
don't see any way to provide robustness to these types of glitches if
you don't validate (and perhaps also select the candidate to use by
measuring latency of the checks you perform) the flows you're about to
use for media traffic.

My point: you cannot take IPv6/IPv4 transitional issues in isolation.
Maybe in a tightly controlled network you could, but I don't see the
point in recommending something that will ultimately just confuse the
rest of the people in the Internet.

Cheers,
Aki

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 21 Mar 2007 13:16:45 -0400

> rest of the people in the Internet.

Another important consideration: in order to do RFC 3484 IPv6 address
selection, one end of the connection has to know the other's set of IPv6
addresses.  For offer/answer, currently ICE is the only mechanism which
would make that possible.  Would advertising a single IPv6 address in SDP
actually be widely useful?

-- 
Jonathan Lennox
[email-masked]

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 12:26:57 -0500

Aki,

Definitely agree with you. People should be encouraged to look at
everything that goes with having multiple paths over which to
communicate. ANAT isn't designed to solve all of these issues. 

However, there are networks being specified that do have a policy of
preferring IPv6 over IPv4 because they have IPv4 only as a fall-back
position for IP version interworking. In this case, only one address
space is supported by one of the endpoints, so there's really not a
choice even though the SDP offer makes it appear that there is one. This
would be a scenario in which ANAT is acceptable for the IPv6/IPv4
interworking.

In order to avoid confusing people, I would be in favor of (and willing
to spend some cycles helping out creating) a document that explains the
issues at hand, what ANAT can safely be used for with and without the
presence of ICE, etc. Rather than just leaving it hanging out there for
people to figure out on their own we can just write it down. That way
they can see clearly an what the milestones would need to be for an
evolution path that makes sense for them without having to hold anything
else up in the process.

Regards,
Brian 

> Sent: Wednesday, March 21, 2007 12:02 PM
> >> If you could ever address the traversal issues in isolation, then 
> >> this would of course make perfect sense. Unfortunately, I 
> think they 
> >> cannot, and as a consequence, it's hard to escape the complexity 
> >> required to make things work reliably.
> > 
> But continuing on the same vein, I did some experimentation 
> with IPv6 here in the IETF meeting. Round-trip times for v6 
> were about twice as long as for v4 (120ms vs. 60ms). (Aside: 
> my very first experiment failed since IPv6 routing to my own 
> domain was looping somewhere in transit. Nice.)
> 
> than IPv4 (latency- or otherwise) you may be disappointed, 
> which in practice means worse than optimal quality, or worse 
> yet, a dead call. I don't see any way to provide robustness 
> to these types of glitches if you don't validate (and perhaps 
> also select the candidate to use by measuring latency of the 
> checks you perform) the flows you're about to use for media traffic.
> 
> Maybe in a tightly controlled network you could, but I don't 
> see the point in recommending something that will ultimately 
> just confuse the rest of the people in the Internet.
> 
> Cheers,
> Aki
> 
>

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 12:39:20 -0500

When dealing with mobile IPv6 deployments, I *believe* that the HA
typically uses a global IPv6 address, which would then be specified in
the SDP via a PMIP type architecture. Someone more familiar with how all
of that works than I might be able to comment if I have that wrong.

So, to at least some folks, I think the answer to your question is yes,
but that one shoe does not fit all. This would be another good datapoint
to capture in a document.

Regards,
Brian

> From: Jonathan Lennox [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 12:17 PM
> To: Aki Niemi
> Cc: Stucker, Brian (RICH1:AR00); Karim El Malki; 
> [email-masked]; Gonzalo Camarillo; Vijay K. Gurbani; 
> Barnes, Mary (RICH2:AR00); sipping
> On Wednesday, March 21 2007, "Aki Niemi" wrote to "ext Brian 
> Stucker, Karim El Malki, [email-masked], Gonzalo 
> Camarillo, Vijay K. Gurbani, Mary Barnes, sipping" saying:
> 
> Another important consideration: in order to do RFC 3484 IPv6 
> address selection, one end of the connection has to know the 
> other's set of IPv6 addresses.  For offer/answer, currently 
> ICE is the only mechanism which would make that possible.  
> Would advertising a single IPv6 address in SDP actually be 
> widely useful?
> 
> --
> Jonathan Lennox
> [email-masked]
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Mar 2007 14:02:52 -0400

inline.

> would be a scenario in which ANAT is acceptable for the IPv6/IPv4

Your point, I think, is that there exist cases where the v6 network will 
always be connected, and will always be better than v4, and will not 
have firewalls and nats. And that, I'll have lots of calls from users in 
those networks to users in the same network. Consequently, in this 
constrained environment, a simpler solution would work.

Sure.

Aki and I are pointing out that this is just one use case, and that the 
reality is that networks will often be heterogeneous with multiple 
networks involved in a call. Its better to have one solution that solves 
all cases than two solutions, one for a very simple case, and another 
that overlaps with the first which then needs to be added later on when 
your assumptions prove wrong.

At a higher level, the real issue in front of us is this. ICE is focused 
on nat traversal, true, but it makes this fundamental design decision 
that *the choice of transport addresses must always be done 
dynamically*. That design choice, and I believe it to be a good one. The 
design decision I am advocating is to apply this same kernel of truth - 
that transport address selection is always done better dynamically - to 
multihoming even when there is no NAT. This would include v4/v6, but 
also interesting cases like a laptop with VPN and wireless and a wired 
interface all up and running. Why IP address should I use for a 
particular call, even when there is no NAT? ANAT *cannot* be used there, 
since ANAT is about the multihoming selection problem just for the v4/v6 
case. ICE covers them all.

Thanks,
-Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 21 Mar 2007 15:02:26 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> 
> Brian Stucker wrote:
> 
> > Aki,
> > 
> > choice even though the SDP offer makes it appear that there is one. 
> > This would be a scenario in which ANAT is acceptable for 
> the IPv6/IPv4 
> > interworking.
> 
> 
> Your point, I think, is that there exist cases where the v6 
> network will always be connected, and will always be better 
> than v4, and will not have firewalls and nats. And that, I'll 
> have lots of calls from users in those networks to users in 
> the same network. Consequently, in this constrained 
> environment, a simpler solution would work.
> 
> Sure.

You can still have firewalls and NATs and things can still work. What
you are saying is that there are a number of  architectures being
proposed, some that I would remind you of your personal recent
involvement in helping specify, that are just plain broken without ICE.

Modernity is rife with constrained environments that are very successful
in their own right. Constrained does not automatically equal broken.

> 
> Aki and I are pointing out that this is just one use case, 
> and that the reality is that networks will often be 
> heterogeneous with multiple networks involved in a call. Its 
> better to have one solution that solves all cases than two 
> solutions, one for a very simple case, and another that 
> overlaps with the first which then needs to be added later on 
> when your assumptions prove wrong.

I agree, and have pointed out that there are cases where you really do
need ICE to get things to work without help from the middle of the
network. I think it's pretty obvious that this is the case. Where we
disagree is that there needs to be a complex solution to a simple
problem. If the problem space is constrained and simple, let it be
simple. Why inject complexity where it's not wanted, asked for, or
needed?

I made a proposal that instead of flatly doing away with ANAT, that a
document be drawn up that clearly shows when you can/should use what. As
people move from one environment to the next, or while defining a
particular environment, they can clearly see what they're getting for
their dollar. I think it's a pretty reasonable suggestion to at least
write it all down so those out there who aren't as intricately involved
with the various WG discussions can understand what the issues are. I
think ICE will come out looking very favorable in such a document,
without having to force a decision on the community.

> 
> At a higher level, the real issue in front of us is this. ICE 
> is focused on nat traversal, true, but it makes this 
> fundamental design decision that *the choice of transport 
> addresses must always be done dynamically*. That design 
> choice, and I believe it to be a good one. The design 
> decision I am advocating is to apply this same kernel of 
> truth - that transport address selection is always done 
> better dynamically - to multihoming even when there is no 
> NAT. This would include v4/v6, but also interesting cases 
> like a laptop with VPN and wireless and a wired interface all 
> up and running. Why IP address should I use for a particular 
> call, even when there is no NAT? ANAT *cannot* be used there, 
> since ANAT is about the multihoming selection problem just 
> for the v4/v6 case. ICE covers them all.

So you've echoed my points, and questioned a claim I never made about
ANAT. I guess you agree with me on this point then?

---

From: Karim El Malki <[email-masked]>
Date: Wed, 21 Mar 2007 22:18:26 +0100

> actually be widely useful?

The discussion is about using ANAT for that and applying 3484 rules.
See draft-ietf-sipping-v6-transition
Karim

---

From: Karim El Malki <[email-masked]>
Date: Wed, 21 Mar 2007 22:48:37 +0100

Reading this thread I'm starting to realise that using ICE
could actually make the transition from IPv6 to IPv4 harder
and less attractive. If you are still forced to run STUN
when you have global ipv6 addresses (i.e. where you don't
need it) then this makes transitioning your SIP service
less attractive right? I think this is a very important
issue that needs to be considered and can have major
impacts i.e. we may be ignoring some of the basic IPv6
advantages. Also I have a feeling that some of the points
raised could be used to support the idea that IPv6 addresses
can be somehow natted. That's something to be avoided.
One of the big points of transitioning to IPv6 is that one
doesn't need to keep sessions alive in nat/gateway boxes
to be reachable. So I agree with Jonathan's point on:
*the choice of transport addresses must always be done
dynamically*. But we shouldn't handle IPv6 as if it were IPv4.
Karim

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 22 Mar 2007 01:12:57 -0500

A possible (?) alternative might be to have an option in ICE where the
candidate addresses are used, but no connectivity checks are performed
by either end. Essentially this would convert the syntax of ANAT into
ICE so we can reduce the number of ways to specify something in SDP
without bringing in the requirement to support any dynamic selection
functionality on either end.

It'd be a step towards ICE without disrupting what is available through
ANAT alone. I guess it'd be a diet ICE-lite.

Regards,
Brian

> From: Mahendran, AC [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 10:10 AM
> To: Stucker, Brian (RICH1:AR00); Gonzalo Camarillo; sipping
> I have similar concerns as Brian. In addition to the 
> increased complexity of implementation, ICE also increases 
> the post-dial delay due to the STUN connectivity checks. I 
> think it is too early to talk about deprecating ANAT. I am 
> more comfortable with ICE+ANAT.
> 
> -AC 
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 22 Mar 2007 10:09:14 +0100

Hi,

it seems people are only discussing two options:

1) ICE alone
2) ANAT alone

I would encourage everybody to have a look at the slides Jonathan 
presented in MMUSIC, which include more options such as ANAT + ICE 
(i.e., two m lines grouped using ANAT, and ICE used in both) or the use 
of SDP capabilities.

Regarding documentation, the SIPPING IPv6 transition document, which 
will be IETF LCed shortly, will explain how to use whatever mechanism we 
choose.

Cheers,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 05:11:50 -0400

inline.

Brian Stucker wrote:

> You can still have firewalls and NATs and things can still work.

With ICE.

> What

I'm saying there are some network architectures were ANAT alone will 
work, and many where it will not. I assert that the ones where it will 
work are not that common, and I think Kai's later note in this thread 
argues, will be even less common during the transition period.

However, more importantly still, is the point that its hard to know IN 
ADVANCE that an endpoint will find itself in such an environment, and 
that this environment won't change. The main thing about ICE is that it 
makes no assumptions on the network architecture, and so a client that 
implements it knows that things will work no matter what.

This is some of the dangerous thinking in system architectures - you 
assume all components of the network are exactly as you specify and 
think they will exist, and then make assumptions at one layer based on 
another layer, when in reality there is very little coupling between 
those layers, especially with IP, so that your assumptions can be 
invalidated almost trivially and your architecture falls to pieces.

Its also a lot like the thinking that led to stun alone in the first 
case - that there is a simple solution (just binding discovery) that 
works in some cases. So lets have a simple solution (stun) to a simple 
problem (user behind a non-symmetric nat and other user not behind the 
same nat), and a more complex solution (turn) for other cases. We found 
it was impossible to determine which topology an endpoint was in, and so 
that led to ICE.

Its also, as Colin pointed out, a lot like the thinking that went into 
the incremental fixes to SDP - best effort SRTP, profile negotiation, 
etc. Here too, we had a decision (and almost a mandate from the ADs) to 
do a more complex, but more general solution to this problem.

I think we should learn from history here.

> simple. Why inject complexity where it's not wanted, asked for, or

Because:

1. things get increasingly compliex overall as we get multiple solutions 
for the same problem.
2. its hard to know for sure that an endpoint is in a topology where it 
can make the assumption where ANAT would work. With ICE, you don't have 
to know.

> ANAT. I guess you agree with me on this point then?

I see little value in having a debate where you simply state that my 
words in fact support your claims and that therefore we are done. Don't 
put words into my mouth. I have plenty of my own.

Thanks,

-Jonathan R.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 05:24:52 -0400

> ANAT alone. I guess it'd be a diet ICE-lite.
This sounds like SDP Capability Negotiation using ICE syntax. I don't 
think that's a good idea. The basic issue here is whether we insist on 
always having  connectivity checks performed as a part of the process 
involved in deciding whether to use a particular IPv4 or IPv6 address. 
If the answer is yes, then we need ICE. If the answer is no, then ICE is 
not the right answer (but should clearly be usable in combination with 
the actual negotiation mechanism used).

-- Flemming

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 05:28:27 -0400

Karim El Malki wrote:

> need it) 

and how does a client know that to be the case?

> then this makes transitioning your SIP service
> less attractive right? 

No. It makes it easier since in the beginning especially IP connectivity 
won't work so well. ICE gives you a guarantee that you won't use the 
IPv6 address unless it actually works.

I think this is a very important
> can be somehow natted.

Well, my feelings on whether there will be NAT in v6 are known. I'd 
rather not debate the likelihood of that however. Even if you ignore 
NAT, do you think there will be firewalls in IPv6? I think most folks 
think so. Would you describe to me how a v6-only host will work in the 
presence of firewalls? Does ANAT help that?

  That's something to be avoided.
> to be reachable. 

Like firewalls you mean. No firewalls in V6? That is a very dubious 
proposition.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 05:32:04 -0400

If you eliminate the connectivity checks you defeat the entire reason 
for ICE - dynamic connectivity. You need to have dynamic address 
selection the moment you have multiple addresses, and that means 
ICE-lite won't work for dual-stack selection.

You *can* specify a mode whereby a host uses full ICE but doesn't gather 
server reflexive or relayed candidates. Maybe this is 'ICE-medium'. The 
benefit here, is that if NATs show up in your architecture, or 
firewalls, the affected endpoint just adds candidate gathering, an 
entirely local change requiring no coordination with any other endpoint, 
and things start working again.

If you deploy ANAT, and then find that NATs or firewalls show up, you 
now need to go and change what the other endpoints in your network need 
to support - they need to add ICE.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 04:33:43 -0500

Can you explain WHY you reach that conclusion?

That seems like a totally arbitrary conclusion to me.

Brian's proposal has the advantage of not defining a new syntax. And
it's not
capability negotiation. It's address negotiation using ICE, but
dispensing from
the connectivity check in some specific case.

> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Thursday, March 22, 2007 02:25
> Cc: Karim El Malki; Mahendran, AC; Gonzalo Camarillo; Vijay 
> K. Gurbani; Barnes, Mary (RICH2:AR00); sipping; mmusic
> > It'd be a step towards ICE without disrupting what is available 
> > through ANAT alone. I guess it'd be a diet ICE-lite.
> >   
> This sounds like SDP Capability Negotiation using ICE syntax. 
> I don't think that's a good idea. The basic issue here is 
> whether we insist on always having  connectivity checks 
> performed as a part of the process involved in deciding 
> whether to use a particular IPv4 or IPv6 address. 
> If the answer is yes, then we need ICE. If the answer is no, 
> then ICE is not the right answer (but should clearly be 
> usable in combination with the actual negotiation mechanism used).
> 
> -- Flemming
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 05:44:34 -0400

Actually, draft-ietf-sippinv-v6-transition says NOTHING about applying 
those rules to media streams. Indeed, by my read, ANAT will 
FUNDAMENTALLY not allow you to apply those rules to media streams, 
whereas ICE will. Here's why.

With ANAT, consider a host with multiple v6 addresses. ANAT requires it 
to order its addresses in priority order using the mid as the priority 
value. Then, the answerer picks the highest priority one that it 
supports. Thus, ANAT requires a prioritization at the offerer PRIOR to 
the offerer knowing the IP addresses that the answerer has. The whole 
idea with RFC 3484 is that the prioritization is done when you have both 
the source and destination address pairs. With ANAT, you can't do that - 
its a causality problem.

With ICE, you can, and without one word of change to the current ICE spec.

The reason is that ICE has this mode of operation called regular 
selection (now the recommended algorithm in -14). In this mode, the 
controlling agent takes ownership of the selection process and can run 
any algorithm it likes for choosing amongst the pairs, including 
completely disregarding the ICE priority ordering, which is just used to 
determine the sequence of checks. Once the offer/answer process ocurrs 
and it has both the source and destination addresses are known to the 
controlling endpoint, checks proceed, and the controlling endpoint 
determines when they stop and which pairs to pick. This allows the ICE 
endpoint to run an algorithm such as: order all pairs based on the 
RFC3484 priority and choose the highest priority pair based on that 
ordering which works.

So, to summarize, if you want to apply RFC 3484 ordering to media 
streams, you have NO CHOICE BUT TO USE ICE. ANAT WILL NOT WORK.

-Jonathan R.

---

From: "Kai Vehmanen" <[email-masked]>
Date: Thu, 22 Mar 2007 11:50:18 +0200

Hello,

On 22 March 2007,  Brian Stucker wrote:
>A possible (?) alternative might be to have an option in ICE 
>where the candidate addresses are used, but no connectivity 
>checks are performed by either end. Essentially this would 
[...]
>It'd be a step towards ICE without disrupting what is 
>available through ANAT alone. I guess it'd be a diet ICE-lite.

I'd say just do ICE-lite then. It doesn't have the architectural
implications of a full ICE implementation, and is _really_ quick to 
implement (have been following one -13/lite effort). Specifically,

 - very little extra state
 - no need to modify interfaces between the signaling and media stack

I encourage everyone to think for a moment about the level of 
effort needed to add at least ice-lite support. If there's something 
in the spec that still causes (architectural) issues to existing SIP 
implementations, this would be a good time to get that feedback.
The biggest complaint I've got from implementors is the change
to the signaling<->media-stack interface (which is painful but hard
to avoid), but ice-lite "fixes" this.

-- 
[email-masked] (Kai Vehmanen)

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 05:55:20 -0400

> That seems like a totally arbitrary conclusion to me.
On the contrary. We had transport address negotiation as part of the 
original capability negotiation proposal and requirements. The reason we 
took it out was because we already had ANAT and didn't want to needlesly 
duplicate existing functionality (and at the time, which admittedly was 
not very long ago, there wasn't much interest in doing that particular 
part).

> the connectivity check in some specific case.
So your argument is that negotiation of IP addresses is different from 
negotiation of transport protocols, codecs, keying material, and all the 
other parameters we include in the SDP and therefore it should be done 
differently by use a completely different attribute ("a=candidate") that 
contains information of no relevance to pure IP-address selection (like 
whether it's UDP or TCP, component ID, etc.) and presumably excludes the 
rest of the ICE attributes since they won't be of relevance without 
connectivity checks (thereby requiring the answerer to figure out which 
of the two intended usage scenarious we are actually in) ? I'm not sure 
how to respond to that except to point to out that you arguing for 
treating a specific part of the SDP differently from the rest of it. 
That seems arbitrary and inconsistent to me.

-- Flemming

>>> A possible (?) alternative might be to have an option in 
>>>       
>> ICE where the 
>>     
>>> candidate addresses are used, but no connectivity checks 
>>>       
>> are performed 
>>     
>>> by either end. Essentially this would convert the syntax of 
>>>       
>> ANAT into 
>>     
>>> without bringing in the requirement to support any dynamic 
>>>       
>> selection 
>>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 04:59:24 -0500

If we use that logic then we would deprecate using candidates in ICE,
no?

I'm fearing that the Capability Negotiation thing will become the
Power Sucking Alien. 

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Thursday, March 22, 2007 02:55
	To: Audet, Francois (SC100:3055)
	Cc: Stucker, Brian (RICH1:AR00); Karim El Malki; Mahendran, AC;
Gonzalo Camarillo; Vijay K. Gurbani; Barnes, Mary (RICH2:AR00); sipping;
mmusic
	Subject: Re: [Sipping] SIP IPv6 Transition: ICE or ANAT

	Francois Audet wrote: 

	On the contrary. We had transport address negotiation as part of
the original capability negotiation proposal and requirements. The
reason we took it out was because we already had ANAT and didn't want to
needlesly duplicate existing functionality (and at the time, which
admittedly was not very long ago, there wasn't much interest in doing
that particular part). 

		Brian's proposal has the advantage of not defining a new
syntax. And
		it's not
		capability negotiation. It's address negotiation using
ICE, but
		dispensing from
		the connectivity check in some specific case.

	So your argument is that negotiation of IP addresses is
different from negotiation of transport protocols, codecs, keying
material, and all the other parameters we include in the SDP and
therefore it should be done differently by use a completely different
attribute ("a=candidate") that contains information of no relevance to
pure IP-address selection (like whether it's UDP or TCP, component ID,
etc.) and presumably excludes the rest of the ICE attributes since they
won't be of relevance without connectivity checks (thereby requiring the
answerer to figure out which of the two intended usage scenarious we are
actually in) ? I'm not sure how to respond to that except to point to
out that you arguing for treating a specific part of the SDP differently
from the rest of it. That seems arbitrary and inconsistent to me. 
	
	-- Flemming 

		  

			-----Original Message-----
			From: Flemming Andreasen
[mailto:[email-masked]] 
			Sent: Thursday, March 22, 2007 02:25
			To: Stucker, Brian (RICH1:AR00)
			Cc: Karim El Malki; Mahendran, AC; Gonzalo
Camarillo; Vijay 
			K. Gurbani; Barnes, Mary (RICH2:AR00); sipping;
mmusic
			Subject: Re: [Sipping] SIP IPv6 Transition: ICE
or ANAT

			Brian Stucker wrote:

				A possible (?) alternative might be to
have an option in 

			ICE where the 

				candidate addresses are used, but no
connectivity checks 

			are performed 

				by either end. Essentially this would
convert the syntax of 

			ANAT into 

				ICE so we can reduce the number of ways
to specify something in SDP 
				without bringing in the requirement to
support any dynamic 

			selection 

				It'd be a step towards ICE without
disrupting what is available 
				through ANAT alone. I guess it'd be a
diet ICE-lite.

			This sounds like SDP Capability Negotiation
using ICE syntax. 
			I don't think that's a good idea. The basic
issue here is 
			whether we insist on always having  connectivity
checks 
			performed as a part of the process involved in
deciding 
			whether to use a particular IPv4 or IPv6
address. 
			If the answer is yes, then we need ICE. If the
answer is no, 
			then ICE is not the right answer (but should
clearly be 
			usable in combination with the actual
negotiation mechanism used).
			
			-- Flemming
			
			_______________________________________________
			Sipping mailing list
https://www1.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: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Mar 2007 06:18:35 -0400

> If we use that logic then we would deprecate using candidates in ICE,
Not at all - they are doing two different things albeit with some 
overlap. ICE candidate attributes indicate a possible IP-address to use 
(as well as whether you use UDP or TCP) - this part overlaps with 
capability negotiation. They also indicate certain properties of those 
addresses as well as a desire/request to run a connectivity check 
algorithm using STUN and based on the outcome of that check, then 
deciding whether to use it or not - this part is clearly above and 
beyond capability negotiation. In a perfect world, we'd eliminate that 
overlap, but I'm not arguing for that. Also note, that you can in fact 
include candidate attributes as capabilities and use them as part of the 
capability negotiation framework if you want to - in order for that to 
work, you'll of course have to ensure that the other supports both 
capability negotiation and ICE. In any case, we seem to be departing 
from the original issue at hand here.

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 05:25:58 -0500

Yes, perhaps that could be a compromise.

Anybody can think of reasons why it wouldn't work?

> From: Kai Vehmanen [mailto:[email-masked]] 
> Sent: Thursday, March 22, 2007 02:50
> To: Stucker, Brian (RICH1:AR00); Mahendran, AC; Gonzalo 
> Camarillo; sipping
> where the 
> available through 
> I'd say just do ICE-lite then. It doesn't have the 
> architectural implications of a full ICE implementation, and 
> is _really_ quick to implement (have been following one 
> -13/lite effort). Specifically,
> 
> effort needed to add at least ice-lite support. If there's 
> something in the spec that still causes (architectural) 
> issues to existing SIP implementations, this would be a good 
> time to get that feedback.
> The biggest complaint I've got from implementors is the 
> change to the signaling<->media-stack interface (which is 
> painful but hard to avoid), but ice-lite "fixes" this.
> 
> --

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 21 Mar 2007 15:47:59 -0400

Hi Jonathan,
I know there's a humm coming up on this - can you email out what an SDP
offer would look like using ICE, offering v4+v6 candidates, instead of ANAT?
I looked through the draft and I don't see one, and the wording in section
13's not helping.  
I am curious how the resultant SDP would look reaching an endpoint not
supporting ICE.
Thanks!

-hadriel

> Sent: Wednesday, March 21, 2007 2:03 PM
> To: Brian Stucker
> Cc: Karim El Malki; [email-masked]; Gonzalo Camarillo; Vijay K.
> Gurbani; Aki Niemi; [email-masked]; sipping; Mary Barnes
> Subject: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> inline.
> 
> Brian Stucker wrote:
> 
> > Aki,
> >
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Kai Vehmanen" <[email-masked]>
Date: Thu, 22 Mar 2007 05:23:01 +0200

Hello all,

On 21 March 2007,  Karim El Malki wrote:
>and less attractive. If you are still forced to run STUN when 
>you have global ipv6 addresses (i.e. where you don't need it) 
>then this makes transitioning your SIP service less attractive 
>right? I think this is a very important issue that needs to be 

isn't it just the opposite (assuming you meant v4-to-v6 above)?

Let's take the SIP client developer point of view. If you use ANAT by
default, you are betting on IPv6 to always work (for e.g. media sessions) 
if an address is available. Now it's easy to see that this will 
not _always_ hold, and especially at the beginning of transition (as people 
have less experience in deploying and operating IPv6 than IPv4 -- there 
will be temporary glitches, configuration errors, and also more
permanent issues familiar from IPv4 networks like firewalls blocking all 
UDP except DNS, etc, etc).

Now how likely the above scenarios are, I don't know, but I've
seen these happen many times, and have heard similar stories from
others. Now as a SIP client developer, you want to be on the 
safe side and maybe leave ANAT disabled in the default configuration 
(a reasonable compromise). And this means that the client won't 
take advantage of IPv6 even if it is there and works, unless 
it is specifically configured to do so.

With ICE, the client developer can safely enable IPv6 support
by default, without risking bad user experience and hard to debug 
problems (for example firewall blocking RTP on IPv6 network, but
not on IPv4). If you can get rid of these corner cases on IPv4
networks (with ICE), surely you don't want them back when moving
to IPv6? And if you can't, why would you then use IPv6?

So basicly both sides win -- developer can enable IPv6 support
immediately and as a default client setting, while operators can 
incrementally enable IPv6 in their networks and have clients utilizing 
IPv6 without any changes to client configuration.

It's also good to note that the problem looks very different from
a client developer (who needs to work with all kinds of access
networks and SIP services), and a "system developer" (who knows what
assumptions on access network and the services can be made).

I'm making these comments with my independent SIP client developer 
hat on. I don't have a strong opinion on what the sipping transition 
documents should say about ANAT. If your access network is configured
correctly, I see no problem using ANAT, but I also don't see (m)any benefits
to using ANAT if you do have ICE implemented, and I can't see myself
relying on ANAT if I don't have detailed information about the access
network. So I really only care about not having any MUSTs in the documents 
that would prevent me from using ICE-no-ANAT-with-IPv4/6 in my client.

Oh well, but to the original question: no, ICE does not make 
transition to IPv6 any less attractive, on the contrary, it makes it 
easier.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Mar 2007 08:36:08 +0100

On 21 Mar 2007, at 19:02, Jonathan Rosenberg wrote:
...
> Its better to have one solution that solves all cases than two  
> solutions, one for a very simple case, and another that overlaps  
> with the first which then needs to be added later on when your  
> assumptions prove wrong.

...which, of course, is also the argument for capability negotiation,  
compared to best effort SRTP.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Thu, 22 Mar 2007 08:40:13 +0100

On 21 Mar 2007, at 21:02, Brian Stucker wrote:
...
> without having to force a decision on the community.

Any proposal to deprecate ANAT -- whether part of ICE, or a separate  
document -- would, I think, have to include such an explanation.

-- 
Colin Perkins
http://csperkins.org/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 05:24:55 -0400

ICE only SDP with v4 and v6 host candidates:

        v=0
        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
        s=
        c=IN IP4 192.0.2.3
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        m=audio 45664 RTP/AVP 0
        a=rtpmap:0 PCMU/8000
        a=candidate:1 1 UDP 2130706178 192.0.2.3 45664 typ host
        a=candidate:2 1 UDP 1694498562 1080:0:0:0:8:800:200C:417A 76638
          typ host

ANAT SDP with v4 and v6 for the same two IP addresses:

        v=0
        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
        s=
        t=0 0
        a=group:ANAT 1 2
        m=audio 45664 RTP/AVP 0
        c=IN IP6 1080:0:0:0:8:800:200C:417A
        a=mid:1
        m=audio 76638 RTP/AVP 0
        c=IN IP4 192.0.2.3
        a=mid:2

ICE+ANAT:

        v=0
        o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
        s=
        t=0 0
        a=group:ANAT 1 2
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        m=audio 45664 RTP/AVP 0
        c=IN IP6 1080:0:0:0:8:800:200C:417A
        a=candidate:1 1 UDP 2130706178 192.0.2.3 45664 typ host
        a=mid:1
        m=audio 76638 RTP/AVP 0
        c=IN IP4 192.0.2.3
        a=candidate:2 1 UDP 1694498562 1080:0:0:0:8:800:200C:417A 76638
          typ host
        a=mid:2

To me, the ICE+ANAT bit is getting pretty complicated. Try explaining to 
a developer why everything is provided twice and you have to implement 
two ways of signaling both addresses.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 04:32:48 -0500

> Well, my feelings on whether there will be NAT in v6 are 
> known. I'd rather not debate the likelihood of that however. 
> Even if you ignore NAT, do you think there will be firewalls 
> in IPv6? I think most folks think so. Would you describe to 
> me how a v6-only host will work in the presence of firewalls? 
> Does ANAT help that?

While my personal preference is to use ICE, I think this point
about firewall is a red herring.

It would work exactly the same way they do today: with the forward
traffic poking the hole in the firewall. This is done all the time
today, and works perfectly well.

(Yes, I understand it means that you have to do bidirectional media:
but so does ICE).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 05:52:57 -0400

Fair point, Francois. It could work without it. ICE will work better for 
a few minor but real reasons:

1. the first few RTP packets get discarded without ICE. Depending on RTT 
delays this could be a few hundred milliseconds worth. With ICE, the 
suicide packets are STUN not RTP, and you never lose a single packet of 
media.

2. if the firewall won't open the pinhole due to some policy reason, 
config reason, implementation bug or whatever, without ICE you won't 
know it and will proceed with the call and one side won't hear the 
other. This is the common complaint about the behavior of VoIP today. 
With ICE, the phone won't ring until the firewall holes are punched and 
verified.

#2 is particularly compelling I think. The claim that in the future voip 
will always 'just work' through firewalls is a bold one; ICE allows for 
ready detection and diagnosis of the cases where it does not work.

-Jonathan R.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 04:56:57 -0500

Your second point is a fair point in many environments. 

> Sent: Thursday, March 22, 2007 02:53
> Cc: Karim El Malki; [email-masked]; [email-masked]; 
> Gonzalo Camarillo; Stucker, Brian (RICH1:AR00); Vijay K. 
> Gurbani; Aki Niemi; sipping; Barnes, Mary (RICH2:AR00)
> Fair point, Francois. It could work without it. ICE will work 
> better for a few minor but real reasons:
> 
> 1. the first few RTP packets get discarded without ICE. 
> Depending on RTT delays this could be a few hundred 
> milliseconds worth. With ICE, the suicide packets are STUN 
> not RTP, and you never lose a single packet of media.
> 
> 2. if the firewall won't open the pinhole due to some policy 
> reason, config reason, implementation bug or whatever, 
> without ICE you won't know it and will proceed with the call 
> and one side won't hear the other. This is the common 
> complaint about the behavior of VoIP today. 
> With ICE, the phone won't ring until the firewall holes are 
> punched and verified.
> 
> 
> #2 is particularly compelling I think. The claim that in the 
> future voip will always 'just work' through firewalls is a 
> bold one; ICE allows for ready detection and diagnosis of the 
> cases where it does not work.
> 
> -Jonathan R.
> 
> Francois Audet wrote:
> 
> >  
> > 
> >>rather not debate the likelihood of that however.
> >>Even if you ignore NAT, do you think there will be 
> firewalls in IPv6? 
> >>I think most folks think so. Would you describe to me how a v6-only 
> >>host will work in the presence of firewalls?
> >>Does ANAT help that?
> > 
> > 
> > While my personal preference is to use ICE, I think this 
> point about 
> > firewall is a red herring.
> >

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 12:08:37 +0200

Hi,

On 22 March 2007,  Francois Audet wrote:
>It would work exactly the same way they do today: with the 
>forward traffic poking the hole in the firewall. This is done 
>all the time today, and works perfectly well.

no, you can't rely on that.

Well, unless you do the HICE, i.e. the "human ICE" (some of you 
have heard this many times already from me this week): 
  - A calls to B
  - B: "hello?" (STUN binding)
  - A: "hello, hello?" (STUN response)
	-> case 1: no media flows in either direction and HICE fails
      -> case 2: media flows A->B but not B->A and so HICE continue...
  - B: "hi, it seems I can hear you but you can't hear me, 
    I'll hang up and try to call you"
      -> failed "human ICE" procedure

Unfortunately, as "human ICE" doesn't support relays, our friends
A&B will most probably have to resort to some robust legacy 
technology in order to communicate here. ;)

The above can happen if firewall (in the access network) of A or 
B blocks UDP. Even in the more common case where holepunching
does work, and you eventually have a birectional UDP flow, you will
potentially lose the early packets. And this is not a corner case, 
but for instance when calling to an announcement server, a very 
real and annoying problem.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 05:15:40 -0500

We are going off topic.

There are ways to deal with the trivial problem you are describing, as
the billions of minutes of VoIP already used have proven.

Let's move on and stop the rethoric. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, March 22, 2007 03:09
> To: Audet, Francois (SC100:3055); [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Barnes, Mary (RICH2:AR00)
> Subject: RE: [MMUSIC] RE: [Sipping] SIP IPv6 Transition: ICE or ANAT
> 
> Hi,
> 
> >While my personal preference is to use ICE, I think this point about 
> Well, unless you do the HICE, i.e. the "human ICE" (some of 
> you have heard this many times already from me this week): 
>   - A calls to B
> Unfortunately, as "human ICE" doesn't support relays, our 
> friends A&B will most probably have to resort to some robust 
> legacy technology in order to communicate here. ;)
> 
> The above can happen if firewall (in the access network) of A 
> or B blocks UDP. Even in the more common case where 
> holepunching does work, and you eventually have a birectional 
> UDP flow, you will potentially lose the early packets. And 
> this is not a corner case, but for instance when calling to 
> an announcement server, a very real and annoying problem.
> 
> --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 06:35:16 -0400

Careful here. I went down this path, to the point I actually started to 
add the ability to use ice-lite when you have both a v4 and a v6 
candidate to ice-14. It doesn't work, the main reason is that as defined 
today, when both endpoints are ice-lite you fallback to non-ICE. Here, 
we'd need to fall back to something which has some parts of ICE (the 
re-invite with the fixed-up pairs, possibly controlling/controlled node 
selection, etc) yet lacks others (the actual checks). This would be very 
difficult to add to ICE.

-Jonathan R.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 07:51:59 -0400

Cool, thanks!
I think if the proposal to deprecate (obsolete) rfc4091 ANAT reaches
consensus, then you should include the first example in ice-15.

I note, too, that the one advantage ANAT has in this case is that in theory
an ANAT offer can be interpreted by both an IPv4-only and IPv6-only non-ANAT
endpoint using their respective address types.  In other words, a dual-stack
ANAT device can send it and it should succeed/work if the answerer is legacy
IPv4 or IPv6, regardless of whether the answerer supports ANAT.  I say "in
theory" because obviously it depends on if the far-end answerer can handle
ignoring unsupported address types in SDP offers, which is certainly not
always the case.  It could just be rejected for that reason.

To your point: "the ICE+ANAT bit is getting pretty complicated", I agree.
But somehow I feel as the author of ICE you live in a fairly glass house in
that regard.  ;)  Not that you had a choice mind you - it is what it needs
to be given the constraints - just that those words make me chuckle, given
the context.

-hadriel

> Sent: Thursday, March 22, 2007 5:25 AM
> To: Hadriel Kaplan
> Cc: 'Brian Stucker'; 'Karim El Malki'; [email-masked]; 'Gonzalo
> Camarillo'; 'Vijay K. Gurbani'; 'Aki Niemi'; [email-masked]; 'sipping';
> 'Mary Barnes'
> Subject: Re: [MMUSIC] Re: [Sipping] SIP IPv6 Transition: ICE or ANAT
>

---

From: Karim El Malki <[email-masked]>
Date: Thu, 22 Mar 2007 13:10:33 +0100

As I wrote previously I am NOT saying that ANAT is better than
ICE or vice versa. However it would seem to be a good idea to
make ICE work with ANAT (given that the ICE-lite option won't work)
such that connectivity checks are mandated on IPv4 but optional
on IPv6. Is this something that can be considered?
Karim

---

From: Aki Niemi <[email-masked]>
Date: Thu, 22 Mar 2007 13:16:36 +0100

> the billions of minutes of VoIP already used have proven.

First there was no problem at all; now it's a trivial problem. Gee, I
think we're making progress here. ;)

Cheers,
Aki

---

From: Karim El Malki <[email-masked]>
Date: Thu, 22 Mar 2007 13:26:24 +0100

Answers inline.

> and how does a client know that to be the case?

it has a global IPv6 address and receives an offer
with a global ipv6 address.

> IPv6 address unless it actually works.

I don't agree with this view where IPv6 networks will have
problems and that connectivity won't work.

> presence of firewalls? Does ANAT help that?

I'm not trying to ignore issues, my reference with respect to
the IPv6 network model is this v6ops document:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-06.txt

Firewalls exist but it is possible to open inbound pinholes.
In enterprise cases where the user has no right to do so then
we should be considering other mechanisms e.g. that tie the
pinholes to the SIP session.

In any case my proposal is not to favour implementation
of ANAT versus ICE. I'd like to keep both and make the
connectivity checks optional for IPv6 until we have more
experience with deployed networks.
Karim

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 08:48:24 -0400

I think you're dreaming if you think IPv6 is going to remove NAT boxes in
people's homes, companies, hotels, etc.  Those little boxes have other value
beyond multiple IP Addresses.  

And firewalls will never go away, and no they won't have static open holes
for media (such is practically impossible anyway).

But I agree with you using ICE may make the transition harder, if you feel
transition requires offering both address families of a dual-stack for media
while signaling uses only one. (personally I don't see this use case being
common)

-hadriel

> From: Karim El Malki [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2007 5:49 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]; Gonzalo Camarillo; Vijay K.
> Gurbani; Aki Niemi; sipping; Mary Barnes
> This

---

From: Aki Niemi <[email-masked]>
Date: Thu, 22 Mar 2007 13:49:37 +0100

> problems and that connectivity won't work.

What do you mean "will have"? I just yesterday posted evidence of those
exact problems now, here, at this very meeting using the laptop from
which I write this note. The problems are real. We need to deal with them.

Quoting from the draft:

>    To implement simple security for IPv6 in, for example a DSL or Cable
>    Modem connected home network, the broadband gateway/router should be
>    equipped with stateful firewall capabilities.

And further down:

>    There should also be an easy interface
>    which allows users to create inbound 'pinholes' for specific purposes
>    such as online-gaming.

What is this "easy interface" if not ICE?

> pinholes to the SIP session.

Write an Internet-Draft.

> experience with deployed networks.

I don't agree with this at all; but I also don't think this matters.
Personally, I believe ICE will become ubiquitous far sooner than IPv6.
I'm sure YMMV.

Cheers,
Aki

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 09:47:01 -0400

I don't understand why you say ICE makes transition harder. Can you 
elaborate on this? Is it just that ICE is more complex than ANAT (no 
dispute there on my part)?

-Jonathan R.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 22 Mar 2007 15:49:01 +0200

On Thursday 22 March 2007 14:10:33 ext Karim El Malki wrote:
> ICE or vice versa.

Advantages of ICE:
- proper support for RFC3484 (particularly important for IPv6)
- hole punching/firewall "friendliness",
- proper diagnostic of connectivity.

The second item is very much IP version-agnostic. In fact, not only v6ops NAP, 
but also the very existence of the v6ops ICMP firewalling consideration draft 
are very strong signs of that.

The last item is as important for IPv6 as for IPv4, even though for completely 
different reasons. In IPv4 cases, we all agree that's because of traversal 
issues. For IPv6, it is definitely required because of broken setups, routing 
problems, transition mechanism brittleness, etc.

You may argue that on a deployed IPv6 network, these IPv6 connectivity issues 
will be fixed (I honestly hope so). *BUT*, during the IPv6/IPv4 coexistence 
and transition period, this is going to be serious issue to be dealt with.

It so happens that ANAT is precisely about IPv6/IPv4 transition. If you assume 
full IPv6 deployment, you do NOT need ANAT anyway, you can simply use plain 
c=IN IP6!

> However it would seem to be a good idea to 

Right, the only corner case where I can find a "failure" is this:

An dual-stack ICE-Lite box invites, using "c=IN IP4" resp. "c=IN IP6" as 
default, a IPv6-only resp. IPv4-only ICE-Lite box.

ICE-Lite is meant for server-class boxes. That is the same problem as having 
an IPv6-only SMTP or DNS server... you just do not do that in the real 
Internet.

And even if you really want to do it, I am sure ICE-Lite could get a 
small "fix" for this corner case, that is much simpler than the whole SDP 
grouping framework and ANAT.

> on IPv6.

IMHO, it's a bad idea, because it's a bad practice.

-- 
Rémi Denis-Courmont

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 09:51:00 -0400

inline.

> problems and that connectivity won't work.

This claim goes against every piece of historical evidence we have seen 
in packet networking over the past decade. Networks fail. They get 
disconnected. Things get misconfigured. People put in firewalls and do 
nasty things with them. They do NAT. How can you seriously think that 
just because we extended the number of bits in the IP address, that all 
of these networking problems will go away?

If anything, problems occur especially during transition periods. It is 
exactly that time that ICE is most useful.

-Jonathan R.

---

From: "Kai Vehmanen" <[email-masked]>
Date: Thu, 22 Mar 2007 15:51:33 +0200

Hi,

On 22 March 2007,  Jonathan Rosenberg wrote:
>Careful here. I went down this path, to the point I actually 
>started to add the ability to use ice-lite when you have both 
>a v4 and a v6 candidate to ice-14. It doesn't work, the main 
>reason is that as defined today, when both endpoints are 
>ice-lite you fallback to non-ICE. Here, we'd need to fall back 

aa, ok, good point, I didn't think that through. 

>to something which has some parts of ICE (the re-invite with 
>the fixed-up pairs, possibly controlling/controlled node 
>selection, etc) yet lacks others (the actual checks). This 
>would be very difficult to add to ICE.

++agreed; 

It's possibly better to stick with 'lite' and 'full' modes for ICE
for now (keeping ICE simple ;)).

So I'll reiterate my earlier comment that I don't have strong
opinions either for or against ANAT. In my view, selecting between 
the three ICE/ANAT scenarios Jonathan described, depends on
what kind of components and/or system you are implementing. As Francois 
noted, when deploying complete systems, you can of course solve 
these issues with other means. I was just pointing out, that
in the specific case of a client developer who needs to minimize
assumptions on the access network, ICE seems like the best candidate,
and once you have full ICE implemented, ANAT is not adding much value. Be 
it IPv4 or IPv6, you want to verify that RTP flows go through and have 
the ability to alert the end-user that the call didn't work. But
this for the one specific case -- others I'm sure have differing
needs...

Thanks,

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 22 Mar 2007 07:16:15 -0500

That's assuming ANAT would work, which is not necessarily true. 

> Sent: Thursday, March 22, 2007 05:11
> To: Jonathan Rosenberg
> Cc: [email-masked]; Gonzalo Camarillo; Stucker, Brian 
> (RICH1:AR00); Jonathan Lennox; Vijay K. Gurbani; Aki Niemi; 
> sipping; Barnes, Mary (RICH2:AR00)
> As I wrote previously I am NOT saying that ANAT is better 
> than ICE or vice versa. However it would seem to be a good 
> idea to make ICE work with ANAT (given that the ICE-lite 
> option won't work) such that connectivity checks are mandated 
> on IPv4 but optional on IPv6. Is this something that can be 
> considered?
> Karim
> 
> > With ANAT, consider a host with multiple v6 addresses. ANAT 
> requires 
> > it to order its addresses in priority order using the mid as the 
> > priority value. Then, the answerer picks the highest 
> priority one that 
> > it supports. Thus, ANAT requires a prioritization at the 
> offerer PRIOR 
> > to the offerer knowing the IP addresses that the answerer has. The 
> > whole idea with RFC 3484 is that the prioritization is done 
> when you 
> > have both the source and destination address pairs. With ANAT, you 
> > can't do that - its a causality problem.
> > 
> > completely disregarding the ICE priority ordering, which is 
> just used 
> > to determine the sequence of checks. Once the offer/answer process 
> > ocurrs and it has both the source and destination addresses 
> are known 
> > to the controlling endpoint, checks proceed, and the controlling 
> > endpoint determines when they stop and which pairs to pick. This 
> > allows the ICE endpoint to run an algorithm such as: order 
> all pairs 
> > based on the
> >>>> Maybe in a tightly controlled network you could, but I don't see 
> >>>> the point in recommending something that will ultimately just 
> >>>> confuse the rest of the people in the Internet.
> >>>
> >>>
> >>>
> >>> address selection, one end of the connection has to know 
> the other's 
> >>> set of IPv6 addresses.  For offer/answer, currently ICE 
> is the only 
> >>> mechanism which would make that possible.  Would advertising a 
> >>> single IPv6 address in SDP actually be widely useful?
> >>>
> >>
> >>

---

From: Karim El Malki <[email-masked]>
Date: Thu, 22 Mar 2007 14:55:20 +0100

answers inline.

> which I write this note. The problems are real. We need to deal with them.

I have bad delays on my IPv4 line but that doesn't make it a rule.
If you were to work on a good native IPv6 connection you wouldn't
have that problem. For the purpose of this discussion I am
assuming a case where an operator introduces IPv6 with equal
quality to IPv4. Take a mobile operator as you mentioned earlier.
What's the difference between IPv6 and IPv4 line quality there?

> What is this "easy interface" if not ICE?

Example: home dsl routers have a web interface for that.

> Personally, I believe ICE will become ubiquitous far sooner than IPv6.

But we are talking about IPv6 transition and not about how
quickly it will happen. I don't think we should get into
discussing when/if IPv6 will happen here.
Karim

---

From: Karim El Malki <[email-masked]>
Date: Thu, 22 Mar 2007 15:14:35 +0100

> exactly that time that ICE is most useful.

You are taking my words out of context. This was in response
to an argument that IPv6 has worse performance than IPv4.
Let's not discuss IPv6 and NATs etc. For my part I'm just
referring to the v6ops drafts where this topic belongs and
has been discussed thoroughly. You have a different view
that should be taken to v6ops. But it's difficult to come
to a conclusion on a v6 transition problem if we don't agree
on the basic ipv6 network model.
Karim

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 22 Mar 2007 09:17:43 -0500

ICE-lite talking to ICE-lite = No ICE at all.

Regards,
Brian 

> Sent: Thursday, March 22, 2007 4:50 AM

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 10:41:54 -0400

Yup, just that.  If the use case for transition is merely that a dual-stack
host needs to offer both address families for media, so that the media can
end up using a different network address type than signaling, then just
doing ANAT is simpler.  Given that simplicity I would also say it would have
a higher chance of being broadly implemented in commercial products.

But then I live in a different world, with a different perspective of how to
solve such problems, or what the problems even are. ;)

-hadriel

> Sent: Thursday, March 22, 2007 9:47 AM
> To: Hadriel Kaplan
> Cc: 'Karim El Malki'; [email-masked]; 'sipping'

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 22 Mar 2007 10:58:10 -0400

> Sent: Thursday, March 22, 2007 9:55 AM
> 

You must be joking.  Gamers are often a technical crowd (though that's been
changing), but voip users??  You honestly think it's reasonable to tell
people to create static/DMZ entries?  And it's not like the media addressing
is known in advance.

Can you show me how to get to such an interface on my hotel's firewall?  I
would really like to bypass its silly policies.
:)

-hadriel