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

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jan 2010 20:25:00 +0100

" 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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Jan 2010 13:42:38 -0600

Elwell, John wrote:
> 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.

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/

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jan 2010 20:58:49 +0100

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 28 January 2010 19:43
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sipping] Question on draft-ietf-sipping-v6-transition-07
> 
> Elwell, John wrote:
[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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Jan 2010 14:09:34 -0600

Elwell, John wrote:
> [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.

Correct; rfc3264 does not specify .invalid.  sipping-v6-transition
is supposed to update rfc3264 to do so.

The two alternative solutions are supporting "::" and ".invalid";
since at the time of writing of sipping-v6-transition, there
wasn't much IPv6 support, instead of mandating both ".invalid"
and "::", we decided to mandate only the ".invalid".  Older,
IPv4 endpoints could continue using "0.0.0.0" while newer
IPv4/IPv6 endpoints will use "0.0.0.0" when communicating
with IPv4 peers and ".invalid" when doing so with IPv6 peers.

Thanks,

- vijay

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jan 2010 21:40:24 +0100

> Sent: 28 January 2010 20:10
> To: Elwell, John
> Cc: [email-masked]
[JRE] My misunderstanding. I thought you were implying there had been two options with IPv4 that we were trying to avoid with IPv6.

> with IPv4 peers and ".invalid" when doing so with IPv6 peers.
[JRE] Thanks,

John