Re: [MMUSIC] Liaison from 3GPP on how to encode theinvalidconnection address in IPv4,

["Philip Hodges" <philip.hodges at ericsson.com>]

Hi,
can you explain to me the process from now on with this LS - will a
draft be circulated on this exploder for further comment before being
returned to CT4 ?

best regards,


Phil Hodges
Ericsson
Mobile: +61404069546
 
 

-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf
Of Philip Hodges
Sent: Tuesday, 29 July 2008 9:18 AM
To: mmusic at ietf.org
Subject: Re: [MMUSIC] Liaison from 3GPP on how to encode
theinvalidconnection address in IPv4, 

Hi Jonathan,
 
I just wanted to clarify that the intended use is strictly within the
bounds of 3GPP SIP-I Core Network. The profile rules will not permit
signalling of unspecified connection address (in any form) outside of
the PLMN so in my understanding provided that IETF would endorse use of
.invalid for "new implementations where no interworking/interoperability
issues would occur" then I dont see a problem with this. I believe the
concern within 3GPP would be that IETF would not permit the use of
.invalid for IPv4 but this does not appear to be the case as described
by Brett below ? So the main concern is receipt of .invalid by existing
IPv4 implementations but 3GPP SIP-I does not have any existing
implementations - it will be first available in Release 8 which is not
yet approved.
Best Regards,
Phil
 
Jonathan Rosenberg wrote:
 
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.

Brett Tate wrote:


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

	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.
	

 
 
 
 
 
 
 
 
 
 
 
 

 

 

Phil Hodges

Core Network Standardisation

Mobile: +61404069546

Fax:       +61395308658





_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic