Subject: RE: [Sipping] Re: I-DACTION:draft-camarillo-sipping-v6-transition -00.txt

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Feb 2005 17:28:43 -0500

Yeah, same here. Thanks for writing this. Very useful 
and timely.

To expand a little further to what Paul was saying, it seems
to me that we may have to expand the concept of dual stack 
support to more than just registration. 

In particular, I'm thinking of Contact in a non-REGISTER
request such as INVITE. Alice probally needs to put both the 
IPv6 and the IPv4 contact (her proxy may support IPv6, but 
Bob may support only IPv4, and if we want the trapezoid to 
complete, it would then need both addresses).

I'm thinking that Via could have a similar issue (or maybe it
doesn't). 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, February 16, 2005 13:30
> To: sipping
> Subject: [Sipping] Re: 
> I-DACTION:draft-camarillo-sipping-v6-transition-00.txt
> 
> 
> Gonzalo,
> 
> This is good. Glad you wrote it.
> 
> I see one omission. You talk about the need for a proxy that converts 
> from v4 to v6 needed to record-route. But you didn't mention 
> GRUUs. This 
> adds another dimension to the reasons for GRUU - any node that isn't 
> dual stack can't use its own address as a GRUU. And the 
> server providing 
> the GRUUs needs to be dual stack as well.
> 
> And a coworker of mine brought up another point regarding the 
> registration of a dual stack endpoint. This is straightforward of the 
> endpoint registers a contact with an FQDN. But if the 
> endpoint doesn't 
> have a DNS name, its not clear how it should register as dual stack. 
> Registering two contacts, without some added indicators, isn't a good 
> idea. But this could be managed using the same instance id 
> proposed for 
> use with GRUU.
> 
> 	Paul
> 
> [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > 
> > 
> > 	Title		: IPv6 Transcition in the Session 
> Initiation Protocol (SIP)
> > 	Author(s)	: G. Camarillo
> > 	Filename	: draft-camarillo-sipping-v6-transition-00.txt
> > 	Pages		: 8
> > 	Date		: 2005-2-15
> > 	
> > This document describes how IPv4 SIP (Session Initiation Protocol)
> >    nodes can communicate with IPv6 SIP nodes.  Additionally, this
> >    document also describes how a SIP user agent that 
> supports IPv4 can
> >    exchange media with one that supports IPv6.  Both single and
> >    dual-stack user agents are considered in the discussions.
> > 
> > A URL for this Internet-Draft is: 
> > 
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-v6-transit
> > ion-00.txt
> > 
> > To remove yourself from the I-D Announcement list, send a message to
> > [email-masked] with the word unsubscribe in 
> the body of the message.  
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> > to change your subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then
> > 	"get draft-camarillo-sipping-v6-transition-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE 
> /internet-drafts/draft-camarillo-sipping-v6-transition-00.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> ----------------------------------------------------------------------
> > ---
> > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> > 
> --------------------------------------------------------------
> -----------
> > In order to maintain computing infrastructure integrity, 
> Cisco Systems
> > Enterprise Messaging Services and InfoSec teams have set a 
> mail policy
> > disallowing executable attachments in email.
> > 
> > This message contained an executable attachment type that is 
> > prohibited
> > by this policy. The attachment has been removed from this 
> message and 
> > copied to quarantine by our systems. It will be held in 
> quarantine for
> > seven days in the event that the content needs to be retrieved.
> > 
> > Please be aware many viruses attempt to look like 
> legitimate email or
> > notifications from anti-virus systems. We will clearly mark 
> a seperation
> > between our notifications and the original email as follows:
> > 
> >   "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION 
> TECHNOLOGY"
> > 
> > For further reference information about viruses and email antivirus
> > efforts within Cisco, please visit:
> > 
> > http://wwwin.cisco.com/it/ems/services/antiviral
> > 
> > If your concern isn't addressed by the information in this 
> > notification
> > or the above web page, you may open a support request:
> > 
> > http://wwwin.cisco.com/support/
> > 
> > Select "Messaging", "Email-Related", "Mail Routing"
> > 
> > Please include in the text of your case the following information:
> > 
> > * Full headers of the message. Documentation on displaying the full
> > headers is available at this URL:
> > 
> > http://wwwin.cisco.com/support/library/faqs/solution002471.html
> > 
> > * This unique quarantine identifier: j1GG0ahj027722
> > 
> > If the matter is urgent, you may follow up by calling one 
> of the below
> > referenced numbers. Please make every effort to provide the above 
> > requested information via the support web tool prior to 
> calling as it 
> > will greatly aid the resolution of your issue.
> > 
> > Americas:
> > 1 408 526 8888
> > 
> > Asiapac
> > +61 2 8446 8888
> > 
> > EMEA
> > +31 20 485 4888
> > 
> > Japan
> > +81 3 5549 6888
> > 
> > US (Toll Free)
> > 1| 800| 888| 8187| (ext.68888)
> > 
> > Thank you for your cooperation,
> > 
> > Enterprise Messaging Services
> > Cisco Systems, Inc
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked] 
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> > 
> 
> _______________________________________________
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Feb 2005 17:41:09 -0500

> complete, it would then need both addresses).

My point about gruu was addressing this issue. It is already specified 
that Contacts (in INVITE, its respone, etc.) need to be globally 
routable. I think maybe we just need some further clarification about 
what "globally routable" means - that it ought to include support for 
both IPv4 and IPv6, which in turn means it has to have a dns name with 
srv support. Then if the endpoint doesn't have such a thing itself, it 
needs to get a gruu from its registrar.

Or one could take the alternative approach, that clients faced with an 
IPv6 address they can't contact directly, must fall back on a dual stack 
outbound proxy to help them.

> I'm thinking that Via could have a similar issue (or maybe it

I don't think there are problems with Via. Aren't there some special 
actions already specified, putting in two entries when switching between 
v4 and v6?

	Paul