Subject: Re: [MMUSIC] Liaison from 3GPP on how to encode the invalid connection address in IPv4

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 4 Jul 2008 07:54:51 -0600

The liaison statement referenced below by Gonzalo indicates that the IPv4 0.0.0.0 is currently used as a means to signal an invalid connection address in IPv4.  The liaison statement asks 
 |  "whether the .INVALID address may be used to 
 |   indicate an unspecified IPv4 connection 
 |   address and does IETF offer any 
 |   recommendation in this respect ?".

--- specification wise
We had a thread on mmusic related to something close to this back in 2004:
http://www.ietf.org/mail-archive/web/mmusic/current/msg02532.html
due to the requirement of rfc 3264 Offer/Answer to require an agent to accept 0.0.0.0 (" An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.").  The thread seemed to conclude that 0.0.0.0 should be used for IPv4 and .invalid for IPv6 but the question of .invalid for IPv4 was not debated directly.

After a quick check, the SDP BNF notations from RFC 4566 and its predecessors RFC 2326 & 3266 seem to allow the use of .invalid for IP4 connections (a connection address may be represented as an FQDN and .invalid is a valid TLD).

--- implementation wise
0.0.0.0 is typically handled by implementers given the 2543 history and the 3264 MUST requirement.  How would today's implementations react to "c=IN IP4 .invalid"?  can folks provide some feedback?

Any inputs, comments and additional thoughts for what to answer to the LS are welcome by July 11.  We will then craft a draft response for the wg review.

Thanks,
Jean-François

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, June 26, 2008 5:31 AM
> To: mmusic
> Cc: Jean-Francois Mule; Joerg Ott; [email-masked]
> Subject: Liaison from 3GPP on how to encode the invalid connection
> address in IPv4
> 
> Hi,
> 
> we have received the following liaison statement from 3GPP. It
> should be
> discussed in MMUSIC.
> 
> https://datatracker.ietf.org/liaison/449/
> 
> Cheers,
> 
> Gonzalo
> IETF liaison manager to 3GPP
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Sat, 5 Jul 2008 08:55:49 +0800

AFAIK, many Cisco's GWs and Phones do not support .invalid for IPv4, just treat it like normal domain name.

-Rockson 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
Sent: Friday, July 04, 2008 9:55 PM
To: mmusic
Cc: Joerg Ott; [email-masked]; Gonzalo Camarillo
Subject: Re: [MMUSIC] Liaison from 3GPP on how to encode the invalidconnection address in IPv4

The liaison statement referenced below by Gonzalo indicates that the IPv4 0.0.0.0 is currently used as a means to signal an invalid connection address in IPv4.  The liaison statement asks  |  "whether the .INVALID address may be used to 
 |   indicate an unspecified IPv4 connection 
 |   address and does IETF offer any 
 |   recommendation in this respect ?".

--- specification wise

--- implementation wise

Thanks,
Jean-François

> we have received the following liaison statement from 3GPP. It should 
> be discussed in MMUSIC.
>

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 7 Jul 2008 02:24:11 -0600

Thank you for the info.

> From: Jaehwan Kim [mailto:[email-masked]]
> Sent: Sunday, July 06, 2008 1:22 AM
> To: Jean-Francois Mule
> Subject: RE: [MMUSIC] Liaison from 3GPP on how to encode the
> invalidconnection address in IPv4
> 
> Hi,
> In RFC2326(RTSP), there is some text as below(Section C.1.7)
> ... the "c=" field is to be set to a suitable null value. For
>    addresses of type "IP4", this value is "0.0.0.0".
> 
> LS looks asking "Invalid" or "Unspecified".
> 
> At least in IMTC PSS AG, an industrial testing forum for 3GPP PSS
> specification, we agreed to use 0.0.0.0 since 2001. So, many off-
> the-shelf phones and servers follow it.
> 
> Regards,
> Jaehwan
> Vidiator
> 
> Sent: Friday, July 04, 2008 10:55 PM
> To: mmusic
> The liaison statement referenced below by Gonzalo indicates that
> the IPv4 0.0.0.0 is currently used as a means to signal an invalid
> connection address in IPv4.  The liaison statement asks
> due to the requirement of rfc 3264 Offer/Answer to require an agent
> to accept 0.0.0.0 (" An agent MUST be capable of receiving SDP with
> a connection address of 0.0.0.0, in which case it means that
> neither RTP nor RTCP should be sent to the peer.").  The thread
> seemed to conclude that 0.0.0.0 should be used for IPv4 and
> .invalid for IPv6 but the question of .invalid for IPv4 was not
> debated directly.
> 
> After a quick check, the SDP BNF notations from RFC 4566 and its
> predecessors RFC 2326 & 3266 seem to allow the use of .invalid for
> IP4 connections (a connection address may be represented as an FQDN
> and .invalid is a valid TLD).
> 
> 
> --- implementation wise
> 0.0.0.0 is typically handled by implementers given the 2543 history
> and the 3264 MUST requirement.  How would today's implementations
> react to "c=IN IP4 .invalid"?  can folks provide some feedback?
> 
> 
> Any inputs, comments and additional thoughts for what to answer to
> the LS are welcome by July 11.  We will then craft a draft response
> for the wg review.
> 
> Thanks,
> Jean-François
> 
>

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 7 Jul 2008 11:39:20 -0400

> The liaison statement referenced below by Gonzalo indicates 
> that the IPv4 0.0.0.0 is currently used as a means to signal 
> an invalid connection address in IPv4.  The liaison statement 
> asks  |  "whether the .INVALID address may be used to 
> due to the requirement of rfc 3264 Offer/Answer to require an 
> agent to accept 0.0.0.0 (" An agent MUST be capable of 
> receiving SDP with a connection address of 0.0.0.0, in which 
> case it means that neither RTP nor RTCP should be sent to the 
> peer.").  The thread seemed to conclude that 0.0.0.0 should 
> be used for IPv4 and .invalid for IPv6 but the question of 
> .invalid for IPv4 was not debated directly.
> 
> After a quick check, the SDP BNF notations from RFC 4566 and 
> its predecessors RFC 2326 & 3266 seem to allow the use of 
> .invalid for IP4 connections (a connection address may be 
> represented as an FQDN and .invalid is a valid TLD).

AFAIK, no rfc has defined TLD ".invalid" to have the same meaning as
"0.0.0.0" within rfc3264.  RFC 3725 does indicate to look for future
specification.  However AFAIK, only draft-ietf-sipping-v6-transition has
updated rfc3264 with such usage but only discusses IP6.

> --- implementation wise
> 0.0.0.0 is typically handled by implementers given the 2543 
> history and the 3264 MUST requirement.  How would today's 
> implementations react to "c=IN IP4 .invalid"?  can folks 
> provide some feedback?

Although it appears valid per rfc4566 ABNF, isn't something needed prior
to ".invalid" to be structured like a valid FQDN?

Until more devices support IPv6, I assume many will not treat IP4 TLD
".invalid" like "0.0.0.0".  However once IPv6 supported, I assume some
will interpret receiving IP4 TLD ".invalid" similar to "0.0.0.0";
however they likely would not send it unless interoperability concerns
have been alleviated.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 21:39:38 -0400

I think its dangerous to assume .invalid will work with IPv4 hosts. Most 
will not know that it means something special, attempt to look it up, 
fail the DNS query, and probably do something like terminate the call. 
We were able to make this work for v6 because there was no backwards 
compatibility issue.

So my response would be that they should not use .invalid for v4.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic