Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 28 January 2010 19:58 UTC

Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9385A3A688B for <sipping@core3.amsl.com>; Thu, 28 Jan 2010 11:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxF2D3q1U432 for <sipping@core3.amsl.com>; Thu, 28 Jan 2010 11:58:33 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 4DC1D3A67DB for <sipping@ietf.org>; Thu, 28 Jan 2010 11:58:32 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-705811; Thu, 28 Jan 2010 20:58:51 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 7FB441EB82AB; Thu, 28 Jan 2010 20:58:51 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 28 Jan 2010 20:58:51 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Date: Thu, 28 Jan 2010 20:58:49 +0100
Thread-Topic: [Sipping] Question on draft-ietf-sipping-v6-transition-07
Thread-Index: AcqgUg6KvTZrJLfYR8OMYoDbd8hofwAAdafA
Message-ID: <A444A0F8084434499206E78C106220CAB4EC49F5@MCHP058A.global-ad.net>
References: <A444A0F8084434499206E78C106220CAB4EC49D8@MCHP058A.global-ad.net> <4B61E8AE.6090309@alcatel-lucent.com>
In-Reply-To: <4B61E8AE.6090309@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipping@ietf.org" <sipping@ietf.org>
Subject: Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2010 19:58:34 -0000

 

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] 
> Sent: 28 January 2010 19:43
> To: Elwell, John
> Cc: sipping@ietf.org
> Subject: Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07
> 
> Elwell, John wrote:
> > " 1.  In some cases, especially those dealing with third party call 
> > control (see Section 4.2 of [12]), there arises a need to 
> specify the
> > IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in the SDP
> > offer.  For this, IPv6 implementations MUST use a domain name within
> > the .invalid DNS top-level domain instead of using the IPv6
> > unspecified address (i.e., ::)."
> > 
> > Can somebody recall the reason for this? Both "0.0.0.0" and 
> "::" mean
> > "unspecified" in their respective IP versions.
> 
> John: Right; so I went back to my email archives to when
> Gonzalo and I had a conversation about this (on April 27, 2006.)
> 
> We favored an .invalid over :: because the Application folks had
> indicated this to be their preference in the past.  For IPv4,
> 0.0.0.0 was supported for backwards compatibility, but it appears
> that a move to IPv6 can be handled cleanly with using only .invalid
> instead of having two alternative solutions.
[JRE] Thanks, Vijay. However, RFC 3264 specifies only 0.0.0.0 for the case where the address is not known in the initial offer (I am not talking about the deprecated use for hold). It does not specify .invalid, so I don't know what you mean by two alternative solutions.

John

> 
> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
>