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

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.

Drage, Keith (Keith) 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
> 
> 
>>-----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
>>
>>_______________________________________________
>>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
>>
> 
> 
> _______________________________________________
> 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
> 

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

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

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
>>> 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
>>>
>>> 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
> 
> 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
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 21 Mar 2007 06:30:05 -0400

How can you have "ICE with ANAT should be disallowed"?
When the offerer sends ICE she doesn't yet know if the other end supports
it.
What if the other end only does ANAT?
-hadriel

> Sent: Wednesday, March 21, 2007 2:06 AM
> To: Gonzalo Camarillo; sipping
> Cc: [email-masked]; Vijay K. Gurbani; Mary Barnes; Karim El Malki
> 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
> 
>

---

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

What I was referring to there was: if you know both endpoints support
ICE, don't use ANAT.

You're correct though. In the initial SDP offer, you wouldn't know.
Point taken.

Regards,
Brian

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 5:30 AM
> To: Stucker, Brian (RICH1:AR00); 'Gonzalo Camarillo'; [email-masked]
> Cc: [email-masked]; 'Vijay K. Gurbani'; Barnes, Mary 
> (RICH2:AR00); 'Karim El Malki'
> When the offerer sends ICE she doesn't yet know if the other 
> end supports 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
> use ANAT if 
> > > 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.
> > >
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

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 

> From: Aki Niemi [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 12:02 PM
> 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:
> >> 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.
> 
> 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 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: "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,
> >

---

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

-- 
[email-masked] (Kai Vehmanen)

---

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: Colin Perkins <[email-masked]>
Date: Thu, 22 Mar 2007 08:36:08 +0100

Colin

---

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

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

---

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

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
> 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.
>   
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: "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: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: 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: 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: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: <[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 
> >firewall is a red herring.
> >
> 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: "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: "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: 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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 22 Mar 2007 09:51:00 -0400

inline.

Karim El Malki wrote:

> 
> 
> I don't agree with this view where IPv6 networks will have
> 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: "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 11:14:01 -0400

The thing that bothers me about this ICE vs. ANAT discussion/decision is
that it makes the assumption that ICE is or will soon become ubiquitous.
That may well happen, but it is far too premature to assume so.  The IETF
has shown time and time again that it is good at specifying protocols, but
bad at mandating market forces by fiat.  The SIP WG is no exception to that.
The market picks and chooses from the work of the ietf, not the other way
around.

So the concern I have is if we start going down this road of "oh we can
deprecate this now", without any evidence that the ICE is successful in the
market, then we are creating yet another head-in-the-sand scenario that made
the ietf ignore NATs to begin with. 

So if the proposal is to actually _deprecate_ ANAT because ICE can do it a
different way, then I think it's too soon.  If the proposal is just to
ignore ANAT with respect to the ICE draft - i.e., support address family
selection natively in ICE without any ANAT syntax needed, then I'm in favor
of that. 

-hadriel

---

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

> Sent: Thursday, March 22, 2007 9:55 AM
> 
> >>   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?
> 
> Example: home dsl routers have a web interface for that.

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

[email-masked]>	<[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]>
Date: Thu, 22 Mar 2007 10:58:10 -0400
Cc: 'sipping' <[email-masked]>, [email-masked]
Subject: [MMUSIC] RE: [Sipping] SIP IPv6 Transition: ICE or ANAT

> Sent: Thursday, March 22, 2007 9:55 AM
> 
> >>   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?
> 
> Example: home dsl routers have a web interface for that.

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

---

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.

> 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: 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: Karim El Malki <[email-masked]>
Date: Thu, 22 Mar 2007 15:14:35 +0100